Error Handling — Interview Questions¶

50+ questions across four tiers (Junior → Mid → Senior → Staff). Covers exceptions vs error codes vs Result, checked vs unchecked, Go's if err != nil / errors.Is / errors.As / %w, never swallowing, adding context, exceptions as control flow, null vs Optional/Result, handle-vs-propagate, resource cleanup, panic/recover, exception safety, logging vs throwing, and API error models. Use it for self-review or interview prep.

Table of Contents¶

• Junior
• Mid
• Senior
• Staff
• Rapid-Fire
• Summary
• Further Reading
• Related Topics

The decision a reader is really making at each call site:

Junior (15 questions)¶

J1. What is error handling, and why does it deserve its own chapter?¶

J2. Exceptions vs error codes vs Result types — name one strength of each.¶

J3. What does "never swallow an exception" mean?¶

try { risky(); } catch (Exception e) { /* nothing */ }

J4. Why are error codes easy to get wrong?¶

J5. What is if err != nil in Go, and is it boilerplate?¶

J6. In Go, how do you add context to an error before returning it?¶

if err != nil {
    return fmt.Errorf("load config %q: %w", path, err)
}

J7. What do errors.Is and errors.As do?¶

J8. What's wrong with returning null to signal "not found"?¶

J9. When should you return an empty list instead of null?¶

J10. What is the difference between handling and propagating an error?¶

J11. What is a finally block for?¶

J12. What is try-with-resources (Java) / with (Python)?¶

try (var in = Files.newInputStream(p)) {
    return read(in);
}   // in.close() runs automatically

J13. What does Go's defer do?¶

f, err := os.Open(path)
if err != nil { return err }
defer f.Close()

J14. Is logging an error the same as handling it?¶

J15. What is a stack trace and why keep it?¶

Mid (15 questions)¶

M1. Checked vs unchecked exceptions — explain the difference.¶

M2. Are checked exceptions good or bad?¶

M3. Why are exceptions for control flow an anti-pattern?¶

M4. What is "catch-and-rethrow without context," and how do you fix it?¶

catch (SQLException e) { throw new SQLException(e); }   // adds nothing

catch (SQLException e) {
    throw new RepositoryException("loading user id=" + id, e);
}

M5. What is exception translation, and why do it?¶

M6. Optional vs Result vs null — when each?¶

M7. Should you wrap every line in try/catch?¶

M8. When is catching everything (catch (Exception) / recover()) actually OK?¶

M9. What is panic/recover in Go, and how does it differ from exceptions?¶

M10. When is it legitimate to recover from a panic?¶

M11. What is exception safety, and name the guarantee levels.¶

M12. How do you implement the strong guarantee?¶

M13. Log vs throw — how do you decide?¶

M14. What's wrong with catch (Exception e) { log.error(e); throw e; } at every layer?¶

M15. How should an error message be written for a maintainer?¶

Senior (12 questions)¶

S1. Design an error model for a public REST/gRPC API.¶

S2. How do you map internal exceptions to API responses without leaking internals?¶

S3. Sentinel errors vs error types vs opaque errors in Go — trade-offs?¶

S4. How do you handle errors across an async / concurrent boundary?¶

S5. What is fail-fast vs fail-safe, and when do you choose each?¶

S6. How does error handling interact with retries, circuit breakers, and timeouts?¶

S7. What is the difference between recoverable and unrecoverable errors, and how should APIs encode it?¶

S8. How do you make errors observable in production?¶

S9. How do you test error paths?¶

S10. How do you safely refactor toward a Result type in a codebase that throws everywhere?¶

S11. What are the hidden costs of exceptions, and when do they matter?¶

S12. How do you handle errors during cleanup (an exception while closing)?¶

Staff (10 questions)¶

S+1. You're setting an org-wide error-handling standard. What goes in it?¶

S+2. How do you choose between exceptions and Result types as a language/platform default?¶

S+3. How does error handling change at the distributed-systems level?¶

S+4. Argue both sides: should a library panic, or always return errors?¶

S+5. How do you prevent error handling from becoming the dominant noise in the codebase?¶

S+6. A team reports "our logs are full of errors but nothing is actually broken." Diagnose.¶

S+7. How do you reconcile fail-fast with high availability?¶

S+8. What is the "errors are values" philosophy and what does it buy you?¶

S+9. How do you design error handling for backward and forward compatibility?¶

S+10. Walk through an incident caused purely by an error-handling mistake.¶

Rapid-Fire¶

Summary¶

Good error handling rests on a few invariants that recur at every tier:

• Make failures visible. Never swallow; never silently return null. Errors-as-values and unignorable Result types beat unchecked codes.
• Handle where you can act; propagate everywhere else — and add context as the error crosses layers (%w, exception chaining), never stripping the cause.
• Separate roles per layer: business code throws/returns meaningful errors; one boundary logs once, maps to the API model, and decides the outcome.
• Reserve exceptions/panics for the exceptional; routine outcomes use return values or conditionals.
• Guarantee cleanup (try-with-resources, defer, finally) and aim for at least basic, ideally strong, exception safety.
• Design the external error model deliberately: stable codes, a consistent envelope, a trace id, no internal leakage.
• At scale, classify errors (transient vs permanent, recoverable vs not) so retries, circuit breakers, and alerts can act on type rather than guesswork.

The recurring trick questions — "is if err != nil bad?", "are checked exceptions good?", "when is catch-all OK?" — all reward the same instinct: name the trade-off and the boundary, don't pick a slogan.

Further Reading¶

• Clean Code, Robert C. Martin — Chapter 7, "Error Handling."
• Effective Java, Joshua Bloch — Items 69–77 (exceptions).
• The Go Programming Language, Donovan & Kernighan — Section 5.4 (errors).
• The Rust Programming Language — Chapter 9, "Error Handling" (Result, panic!, ?).
• RFC 9457 — Problem Details for HTTP APIs.
• Andrew Gerrand, "Error handling and Go"; Dave Cheney, "Don't just check errors, handle them gracefully."

Related Topics¶

• Chapter README — the positive rules for error handling.
• junior.md — junior-level definitions and examples.
• professional.md — advanced patterns and production concerns.
• Defensive vs Offensive Programming — fail-fast, assertions, and input validation.
• Anti-Patterns — the failure modes (exception swallowing, error-code neglect) catalogued as smells.