Error Handling — Optimize & Reconcile¶

Clean error handling and fast error handling are usually the same thing — but not always. This file collects the cases where the two pull apart: where the textbook-clean error path allocates, throws, or logs its way into a profiler flame graph, and where the obvious "fast" hack quietly corrupts your control flow. Each scenario gives a concrete cost (benchmarked or first-principles), then a resolution that keeps the code clean and keeps the error path off the critical path. Languages: Java, Go, Python.

Table of Contents¶

1. JVM exception construction: fillInStackTrace dominates
2. Exceptions as control flow are both slow and unclean
3. Stackless / pre-allocated exceptions in hot validation paths
4. Python exception overhead: try is cheap, raise is not
5. Go: errors.New allocates — sentinel reuse vs per-call construction
6. The cost of wrapping vs the value of context
7. Error-path allocation inside hot loops
8. panic/recover cost and where it actually belongs
9. Eager vs lazy error-string building
10. Logging on the error path: I/O, formatting, sampling
11. Retry/backoff tuning: clean retries that melt the backend
12. Checked-exception wrapping that defeats the JIT
13. Optional/Result vs exceptions on the hit-vs-miss ratio

Scenario 1¶

JVM exception construction: fillInStackTrace dominates.

A validation layer throws a custom ValidationException per bad field. Under load testing, profiling shows ~40% of CPU inside java.lang.Throwable.fillInStackTrace — a native method that walks the entire call stack and snapshots it. The actual validation logic is a few comparisons; the exception is the expense.

public class FieldValidator {
    public void validate(Field f) {
        if (f.value() == null) {
            throw new ValidationException("missing: " + f.name());
        }
    }
}

public List<Violation> validate(Field f) {
    if (f.value() == null) return List.of(new Violation(f.name(), "missing"));
    return List.of();
}

public class ValidationException extends RuntimeException {
    public ValidationException(String msg) {
        super(msg, null, /*enableSuppression*/ false, /*writableStackTrace*/ false);
    }
}

Scenario 2¶

Exceptions as control flow are both slow and unclean.

A parser uses exceptions to signal "this token doesn't match, try the next rule." Every backtrack throws and catches. The code reads like a maze, and a flame graph shows the parser spending most of its time constructing exceptions.

Node parseExpr(Tokens t) {
    try { return parseSum(t); }
    catch (NoMatch e) {
        try { return parseProduct(t); }
        catch (NoMatch e2) { return parseAtom(t); }
    }
}

Optional<Node> tryParseSum(Tokens t) { ... }   // returns empty on no-match

Node parseExpr(Tokens t) {
    return tryParseSum(t)
        .or(() -> tryParseProduct(t))
        .or(() -> tryParseAtom(t))
        .orElseThrow(() -> new ParseException(t.position()));  // genuinely exceptional
}

Scenario 3¶

Stackless / pre-allocated exceptions in hot validation paths.

You've decided an exception is genuinely the right control structure (it propagates across many frames, and the caller several levels up handles it), but the throw site is hot and the stack trace is never read. You want the propagation semantics without the capture cost.

final class ControlFlow {
    // Singleton: no stack trace, no per-throw allocation.
    static final EofException EOF = new EofException();
}

Scenario 4¶

Python exception overhead: try is cheap, raise is not.

A dictionary-heavy hot loop chooses between LBYL (look before you leap) and EAFP (easier to ask forgiveness than permission). A teammate claims EAFP is "always Pythonic," another claims it's "always slow." Both are wrong; it depends on the hit rate.

# EAFP
def get(d, k):
    try:
        return d[k]
    except KeyError:
        return DEFAULT

Scenario 5¶

Go: errors.New allocates — sentinel reuse vs per-call construction.

A storage layer returns errors.New("not found") on every cache miss. Misses are 30% of traffic. pprof shows allocations from this line; worse, callers can't reliably detect the condition because string comparison is brittle.

func (c *Cache) Get(k string) ([]byte, error) {
    v, ok := c.m[k]
    if !ok {
        return nil, errors.New("not found") // allocates a new *errorString every miss
    }
    return v, nil
}

var ErrNotFound = errors.New("not found") // allocated exactly once, at init

func (c *Cache) Get(k string) ([]byte, error) {
    v, ok := c.m[k]
    if !ok {
        return nil, ErrNotFound // zero allocation; just returns the interface value
    }
    return v, nil
}

return nil, fmt.Errorf("cache get %q: %w", k, ErrNotFound)

Scenario 6¶

The cost of wrapping vs the value of context.

A Go service wraps every error at every layer: fmt.Errorf("layer X: %w", err) in the repository, the service, and the handler. The resulting message is a useful breadcrumb trail — but a -benchmem run shows the error path allocating 3× more than necessary, and one engineer proposes removing all wrapping "for speed."

Scenario 7¶

Error-path allocation inside hot loops.

A batch processor handles millions of records. ~2% are malformed. The error branch builds a rich error object — formatted message, captured inputs, a slice of validation details — and appends it to a results list. Profiling shows the error branch, hit only 2% of the time, accounting for 25% of allocations because each error object is large.

errors = []
for rec in records:                 # 5M records
    if not valid(rec):
        errors.append({
            "record": dict(rec),     # full copy of the record
            "message": f"invalid record {rec.id}: {describe(rec)}",
            "context": gather_context(rec),  # extra dict
        })

@dataclass(frozen=True, slots=True)
class RecordError:
    record_id: int       # just the id, not a full copy
    code: str            # an enum-like code, not a formatted string

errors: list[RecordError] = []
for rec in records:
    if not valid(rec):
        errors.append(RecordError(rec.id, validation_code(rec)))

# Formatting happens once, later, only for errors we actually report:
def render(e: RecordError, source) -> str:
    return f"invalid record {e.id}: {describe(source[e.id])}"

Scenario 8¶

panic/recover cost and where it actually belongs.

A Go HTTP middleware wraps every handler in defer recover() to convert panics into 500s — correct and idiomatic. A second team copies the pattern inside a hot request-parsing function to "gracefully handle" malformed input, panicking on bad bytes and recovering locally. Benchmarks show the parser is now 3× slower on malformed input, and the defer adds overhead even on the success path.

func parse(b []byte) (Token, error) {
    if !valid(b) {
        return Token{}, ErrMalformed // sentinel, zero alloc
    }
    ...
}

Scenario 9¶

Eager vs lazy error-string building.

A logging-adjacent hot path constructs a detailed error message before checking whether anyone will use it. In Java, the String concatenation and toString() of large objects run on every iteration, even though the error is rarely thrown and the message rarely logged.

for (Record r : records) {
    String msg = "Processing record " + r.getId()
               + " with payload " + r.getPayload()      // expensive toString
               + " at " + Instant.now();
    if (!isValid(r)) {
        throw new ProcessingException(msg);              // msg built every iteration, used 2%
    }
    process(r, msg);  // msg actually only needed on error
}

for (Record r : records) {
    if (!isValid(r)) {
        throw new ProcessingException(
            "Processing record " + r.getId()
          + " with payload " + r.getPayload()
          + " at " + Instant.now());                     // built only on the 2% path
    }
    process(r);
}

log.debug("state = " + expensiveDump());        // expensiveDump() always runs
log.debug("state = {}", expensiveDump());        // still runs — args eval before call!
log.debug("state = {}", () -> expensiveDump());  // Supplier: runs only if DEBUG enabled

Scenario 10¶

Logging on the error path: I/O, formatting, sampling.

A service logs a full stack trace at ERROR on every failed request. During an incident, the failure rate spikes to 60%, and the logging itself — synchronous, formatting full traces, writing to disk/stdout — becomes the bottleneck. The log volume also blows past the ingestion quota and the real signal is buried.

Scenario 11¶

Retry/backoff tuning: clean retries that melt the backend.

A client wraps every downstream call in a tidy retry helper: 5 attempts, fixed 100 ms delay. The code is clean and the happy path is fine. Then the downstream has a partial outage — and the retries turn a degraded backend into a dead one, because every client synchronously hammers it 5× in lockstep.

def call_with_retry(fn, attempts=5, delay=0.1):
    for i in range(attempts):
        try:
            return fn()
        except TransientError:
            time.sleep(delay)          # fixed delay, no jitter, retries everything
    raise

def call_with_retry(fn, attempts=5, base=0.1, cap=2.0):
    for i in range(attempts):
        try:
            return fn()
        except TransientError:
            if i == attempts - 1:
                raise
            sleep = min(cap, random.uniform(0, base * (2 ** i)))  # full jitter, capped
            time.sleep(sleep)

Scenario 12¶

Checked-exception wrapping that defeats the JIT.

A Java method on a hot path catches a checked exception and rethrows it wrapped in a RuntimeException — standard "sneaky rethrow" cleanup. But the catch block is large and lives in the same method as the hot loop, and the JIT declines to inline the method, so the whole loop runs interpreted-ish for longer and never reaches peak performance.

public int sumLengths(List<Path> paths) {
    int total = 0;
    for (Path p : paths) {
        try {
            total += Files.readString(p).length();
        } catch (IOException e) {
            throw new UncheckedIOException(e);   // big try/catch inflates method bytecode
        }
    }
    return total;
}

public int sumLengths(List<Path> paths) {
    int total = 0;
    for (Path p : paths) {
        total += readLength(p);          // small, inlinable
    }
    return total;
}

private static int readLength(Path p) {
    try {
        return Files.readString(p).length();
    } catch (IOException e) {
        throw new UncheckedIOException(e);
    }
}

Scenario 13¶

Optional/Result vs exceptions on the hit-vs-miss ratio.

A repository's findById returns Optional<T>. A reviewer argues it should throw NotFoundException instead "because that's cleaner." Which is right depends on a number you can measure: how often the lookup misses.

Rules of Thumb¶

• The cost of an exception is the stack trace, not the throw. On the JVM, fillInStackTrace dominates; suppress it (writableStackTrace=false) or pre-allocate a singleton only when the trace is provably useless — and profile before you do either.
• Frequency decides the mechanism. Expected, frequent failure → return a value (Optional/Result/sentinel error). Rare, invariant-violating failure → throw/panic. If a "..._returnsError..." test passes often in production, it isn't exceptional.
• Never use exceptions for control flow. It is the one case where clean and fast agree without compromise — slow and unreadable.
• Go: declare sentinels once, wrap with %w only where context is read. var ErrX = errors.New(...) at package scope; errors.Is to test; fmt.Errorf("...%w", ...) at the boundary that reports, not on every internal miss.
• Capture cheap, render lazy. On hot error paths, capture a minimal identifying key; defer expensive message/context construction to the cold reporting path. Move string-building inside the if.
• Python: try is ~free, raise is not. EAFP for rare misses; LBYL or a purpose-built API (dict.get, defaultdict) when misses are common. Never broad-except in a hot loop.
• panic/recover is a process/request-boundary safety net, not routine control flow. It is both un-idiomatic and measurably slower for expected input.
• Log smart on the error path: async appenders, sample repeated errors, log the trace once with a correlation id, and use the right level. The error path must not amplify the incident that triggered it.
• Retries need backoff, jitter, transient-only filtering, and a circuit breaker. A clean retry helper with naive defaults is an outage waiting for a partial failure.
• Keep try/catch blocks small and close to the failing call. Better diagnostics, better JIT inlining, clearer code — all at once.
• Measure before trading clarity for speed. Every numeric claim here is a starting hypothesis; confirm with async-profiler / JFR (Java), go test -benchmem + pprof (Go), or timeit/py-spy (Python) on your path.

Related Topics¶

• README.md — the positive error-handling rules this file reconciles against.
• find-bug.md — the correctness bugs that hide behind swallowed and mis-modeled errors.
• professional.md — team conventions for consistent wrapping, levels, and error taxonomies.
• ../18-logging-and-diagnostics/README.md — the logging discipline that keeps the error path cheap.
• ../../functional-programming/README.md — Result/Either modeling for errors-as-values.