Java Exception-Handling Best Practices — Anti-Patterns and Their Fixes

Q: Java Exception-Handling Best Practices — Anti-Patterns and Their Fixes

The non-negotiables: **(1)** never catch `Exception` or `Throwable` as a blanket — catch the narrowest type; **(2)** never swallow with empty catch — at minimum log with context; **(3)** always preserve the cause via `throw new X(msg, cause)`; **(4)** throw early, catch at boundaries — validate inputs with `IllegalArgumentException`, handle at the request/transaction boundary; **(5)** prefer unchecked custom exceptions with structured fields (`orderId`, `errorCode`) for REST error mapping; **(6)** use try-with-resources for any `AutoCloseable`; **(7)** don't use exceptions for control flow — stack trace capture is expensive; **(8)** in Spring, use `@ControllerAdvice` + `@ExceptionHandler` so domain exceptions map to structured HTTP responses; **(9)** never catch `InterruptedException` silently — restore the interrupt flag or rethrow.

Intermediate·3 min read·

AmazonGoogleMicrosoftStripeNetflix

Fast recall

Quick revision

Core answer

The non-negotiables: (1) never catch Exception or Throwable as a blanket — catch the narrowest type; (2) never swallow with empty catch — at minimum log with context; (3) always preserve the cause via throw new X(msg, cause); (4) throw early, catch at boundaries — validate inputs with IllegalArgumentException, handle at the request/transaction boundary; (5) prefer unchecked custom exceptions with structured fields (orderId, errorCode) for REST error mapping; (6) use try-with-resources for any AutoCloseable; (7) don't use exceptions for control flow — stack trace capture is expensive; (8) in Spring, use @ControllerAdvice + @ExceptionHandler so domain exceptions map to structured HTTP responses; (9) never catch InterruptedException silently — restore the interrupt flag or rethrow.

Interview-ready guide

Interview answer

The way I frame exception handling is "throw early, catch at boundaries" — lower layers throw specific domain exceptions with the cause preserved, and a single boundary handler translates them to responses.

The catch-side anti-patterns I look for in code review

Blanket catch (Exception e) outside the request boundary — hides bugs
Empty catch block — the failure disappears; at minimum log with context
Losing the cause on rethrow — always pass cause to the constructor; the stack trace is the only artifact production debugging has
Silently catching InterruptedException — restore the flag with Thread.currentThread().interrupt() or rethrow; otherwise cancellation breaks

The throw-side anti-patterns

throws Exception on an API — defeats the contract; declare specific types
Exceptions for control flow — stack capture is expensive; validate explicitly instead
Returning null or sentinel -1 for failures — makes every caller remember a check; use Optional for expected-absence, exceptions for real failures
Wrapping every checked exception in bare RuntimeException — caller loses the ability to catch precisely; use a domain-specific unchecked type

The pattern that works

Repository catches SQLException, throws OrderNotFoundException(id, cause)
Service has no try-catch — just lets exceptions propagate
@ControllerAdvice catches domain exceptions and returns structured JSON with the right HTTP status
Try-with-resources for every AutoCloseable — suppressed-exception handling is free

Recommendation: Default to unchecked custom exceptions with preserved causes plus a global `@ControllerAdvice` handler. Reserve checked exceptions for APIs where the caller genuinely has a recovery path. Never swallow, never lose the cause, never use exceptions for control flow, and always restore the interrupt flag on InterruptedException.

03 · Deep dive