テーマ： error-handling
-
Checking whether a task wrapper hid the failure of its inner command
Determine whether a reported successful task actually propagated the outcome of the compiler, test runner, or migration command on which success depends.
-
Go error handling: wrapping with %w, errors.Is and errors.As
Go functions return errors as ordinary values; add context with fmt.Errorf and the %w verb so the original stays reachable, then test the chain with errors.Is for sentinel values and errors.As (or the generic errors.AsType) for types, instead of comparing strings or using ==.
-
Handling errors in Promises and async/await
An async function turns a throw into a rejection and await rethrows it; every rejection needs an owner. Wrap only what you can recover from, never leave a promise floating, use allSettled when partial failure is acceptable, and register a last-resort unhandledrejection handler.
-
Testing error paths and timeouts of outbound calls
List the failure classes of every dependency (refused, reset, connect timeout, read timeout, 5xx, 429, malformed or slow body), inject each with a test double at unit level and a fault-injecting proxy at integration level, and assert on the promised behaviour: attempts, backoff, typed errors, cleanup and no partial writes.
-
Result, Option and the ? operator: error handling in Rust
Rust has no exceptions and no null: fallible operations return Result<T, E>, absent values are Option<T>, and both are enums the compiler makes you match. The ? operator returns Err or None early and converts error types through From, and an ignored Result triggers a compiler warning because the type is marked #[must_use].
機械可読： JSON