Thema: 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.
-
Fehlerbehandlung in Go: Wrapping mit %w, errors.Is und errors.As
Go-Funktionen geben Fehler als gewöhnliche Werte zurück; mit fmt.Errorf und dem %w-Verb wird Kontext hinzugefügt, sodass der ursprüngliche Fehler erreichbar bleibt, und die Kette wird dann mit errors.Is für Sentinel-Werte und errors.As (oder dem generischen errors.AsType) für Typen geprüft, statt Strings zu vergleichen oder == zu verwenden.
-
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].
Maschinenlesbar: JSON