Error Handling
56 bites tagged Error Handling — interview questions with model answers, and 60-second explainers.
When to panic in Go versus Rust
Both reserve panic for unrecoverable bugs and use values, Result or error, for expected failures; Rust's type system pushes more cases to Result. error philosophy and panic boundaries.
Refactoring under Go simplicity versus Rust correctness
Rust's type system catches broken invariants at compile time so refactors are guided; Go's explicitness keeps code readable but shifts safety to tests and discipline. how language philosophy shapes refactors.
Write a TypeScript async/await function that requests webcam access and handles errors
This tests async/await error handling for getUserMedia and stream attachment. A good answer uses try/catch, sets video.srcObject, and branches on NotAllowedError and NotFoundError. A red flag is omitting catch or using src instead of srcObject.
Write an IndexedDB add function with transaction error handling
Tests IndexedDB request-transaction lifecycle and event-driven error propagation. Answers open a transaction, call add(), and wire onsuccess/onerror on the request plus onabort/onerror on the transaction. Red flag: ignoring onabort or duplicate-key throws.
Create a generic fetchJson wrapper with typed response and error handling
Generic T parameter, optional RequestInit, throw if !res.ok, return res.json() as Promise<T>. marrying TypeScript generics to fetch for typed responses and runtime error handling. using any or omitting the ok check.
Write a typed async fetchUser with error handling
Tests promise-based fetch plus TypeScript return-type contracts. A strong answer checks response.ok before response.json() and types the return as Promise<User>. A red flag is swallowing 4xx/5xx errors silently.
How would you modify fetch to handle HTTP error statuses?
Verify response.ok in then and throw if false, then catch network failures separately. awareness that fetch resolves on HTTP errors and needs manual status checking.
Operational vs Programmer Errors in Node
Operational errors are expected problems like a failed network request; programmer errors are bugs like reading undefined. Handle the first gracefully, crash the second. The footgun is catching programmer errors and continuing, which corrupts process state.
Compare Go's error tuples to Rust's Result for I/O
Tests trade-offs between Go's explicit error returns and Rust's Result type. Contrast Go's inline err checks with Rust's ? operator, noting verbosity versus compile-time exhaustiveness. Never call Result an exception or claim Go ignores errors.
Read a file into a byte slice in Go and Rust
This tests standard-library convenience APIs for slurping files. In Go, use os.ReadFile (1.16+) returning ([]byte, error). In Rust, use std::fs::read returning Result<Vec<u8>>. A red flag is opening a file and looping over reads when a one-liner exists.
Design a custom Go error type with context, Is, As, and Unwrap
This tests Go 1.13 error wrapping and Unwrap conventions. Answer: struct with Err and context fields; implement Error and Unwrap; note errors.Is and errors.As walk the chain. Red flag: stringifying the error via fmt.Errorf %v, which severs unwrapping.
How does the question mark operator use From to unify error types?
This tests Rust error conversion mechanics. You define a unified enum error and implement From for each source error so ? automatically converts via From::from. A red flag is suggesting manual match or map_err on every call instead of trait-based conversion.
What is the difference between unwrap and expect on Option and Result?
It tests your Rust error-handling discipline and justified panics. Both extract values or panic, but expect adds a custom message. Use them only for unrecoverable invariant violations, not routine errors. A red flag is using them as lazy error propagation.
Difference between errors.Is and errors.As in Go
This tests error-chain inspection in Go. errors.Is checks sentinel equality through wrapping, such as os.ErrNotExist. errors.As extracts a custom type, like os.PathError, into a variable. A red flag is using direct == or type assertions on wrapped errors.
Rust's operator equivalent to Go's if err != nil return err
Tests if you know Rust's ? operator for error propagation. A strong answer names ?, explains it returns Err from the function via Result's Try and FromResidual traits, and unwraps Ok. Red flag: calling it .unwrap() or suggesting manual match is idiomatic.
What are Rust Result's variants and how does the compiler enforce handling?
This tests Rust's explicit error model. A strong answer names Ok(T) and Err(E), explains must_use warns when Results are ignored, and notes pattern matching or ? is required to extract values.
How do you idiomatically return a recoverable error and result in Go?
This tests Go's multiple-return error idiom. A strong answer gives a (T, error) signature with error last, returns nil on success, and checks err before using the result. A red flag is suggesting panic for recoverable errors or pointer out-parameters.
Sum Some values in Vec<Option<i32>>, ignoring None
Tests Rust Option handling and null-safety design. A strong answer uses map, unwrap_or, flatten, or match to skip Nones safely, and explains Option replaces null pointers with explicit enum variants. Red flag: using unwrap in a loop or suggesting null checks.
Parse a string to integer in Go and Rust with errors
This tests whether you map each language's error philosophy to syntax. Outline: Go returns (int, error) and callers check err != nil; Rust returns Result<i32, E> and callers match Ok/Err. Red flag: suggesting exceptions or ignoring Rust's must-use Result.
FFI Error Handling: Translation and Unwinding
FFI error handling is a translation layer: foreign errors must become Rust Results before safe code sees them, or you risk UB. You do this in -sys wrappers around C libraries. The footgun: foreign exceptions unwinding across boundary without -unwind ABI is UB.
Describe a robust error handling strategy for network requests
Tests whether you classify failures by layer rather than catching everything generically. Inspect DioExceptionType for connectivity, check HTTP status before parsing, and isolate JSON decode errors. Never show the same message for timeouts and 500s.
Difference between Future<void> and void from an async function
Future<void> lets callers await and catch errors; void hides the Future, preventing await and leaving exceptions uncaught. Knowledge that async always produces a Future. Believing void async returns are awaitable.
Define a Dart Future, return Future<String>, and handle errors with both patterns.
Tests Dart async primitives and error handling. A strong answer defines Future as a pending async result, writes a delayed Future<String>, consumes it with then/catchError, and mirrors with async/await try/catch.
Flutter Network Errors: Fail Gracefully
Treat every network call as a promise that might break. In Flutter, catch exceptions at the HTTP boundary and map them to UI states like retry widgets. The footgun is letting Dio or http exceptions bubble up, crashing the app instead of degrading gracefully.
Get Error Handling bites daily.
Five a day, five minutes, offline. With quizzes so it sticks.
Open testing — you’ll join as an early tester.