Log-and-Rethrow Anti-Pattern in Java
Fast recall
Quick revision
Core answer
Production-quality exception handling awareness — understanding how exceptions propagate in layered architectures
Logging in every catch block and then rethrowing — three layers means three log entries for the same error
Explain the correct pattern: log once at the top (global handler or boundary), let exceptions propagate without logging in intermediate layers
Interview-ready guide
Interview answer
I normally avoid logging and rethrowing the same failure at every layer because one incident becomes several stack traces and distorts monitoring. Intermediate layers should let it propagate or translate it at a real abstraction boundary while preserving the cause. The HTTP handler, message listener, or job runner that finally handles the failure normally logs it once.
It is a guideline rather than a law. If a layer owns diagnostic information that cannot be carried safely with the exception, or must emit an audit event, it can log a distinct event deliberately. I avoid duplicate wording and sensitive data.
Log-and-Rethrow Anti-Pattern in Java
Direct Answer
Logging and rethrowing the same failure at several layers creates duplicate log events for one incident. Usually a lower layer should add context by wrapping with the original cause and let the final handling boundary log once. Logging before rethrowing can be justified when that layer owns unique diagnostic information, but it should be a deliberate exception, not the default.
Common Mistakes & Pitfalls
- Logging in Every Catch Block: Writing
log.errorin every layer's catch block before rethrowing — a three-layer application logs the sameSQLExceptionthree times, making it look like three separate errors occurred. - Using printStackTrace: Calling
e.printStackTrace()in catch blocks, which writes toSystem.errnot your logging framework — this output doesn't get captured by log aggregation tools and isn't structured with timestamps or log levels. - Logging Then Swallowing: Logging the exception but not rethrowing it when the calling code needs to know the operation failed — this creates silent failures where the error is logged but the application continues with bad state, causing confusing downstream errors. The service layer thinks the order was created but it actually failed, leading to inventory problems that manifest hours later.
Check your understanding
Answer these without looking back at the article.
- Where should exceptions be logged in a Spring application?
- What is @ControllerAdvice and how does it centralize exception logging?
- How do you avoid duplicate log entries in a Spring Boot application?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.