Why I Stopped Writing Exception Handlers in Every Spring Boot Service
One of my favorite things about Spring Boot is how easy it is to get started.
Until exception handling enters the picture.
At first, it’s simple.
You create a @RestControllerAdvice.
Handle a couple of business exceptions.
Return a consistent error response.
Done.
Then the application grows.
Suddenly you’re handling validation exceptions.
Authentication failures.
Access denied.
JPA exceptions.
Media type errors.
JSON parsing errors.
Method argument errors.
Missing parameters.
Type mismatches.
And before long, your once-simple exception handler has become one of the biggest classes in the application.
I’ve been there more than once.
After building enough services, I noticed I wasn’t solving business problems anymore—I was rebuilding the exact same exception handling infrastructure in every project.
That became the motivation behind nerv-exception.
The real problem isn’t writing exception handlers
Creating an exception handler isn’t difficult.
The difficult part is keeping every service consistent.
One service returns:
{
"message": "User not found"
}
Enter fullscreen mode Exit fullscreen mode
Another returns:
{
"error": "USER_NOT_FOUND",
"message": "..."
}
Enter fullscreen mode Exit fullscreen mode
A third includes timestamps.
Another includes trace IDs.
HTTP status codes aren’t always consistent.
Some services expose raw exception messages.
Others don’t.
Eventually every microservice speaks a different error language.
For consumers, that’s frustrating.
For developers, it’s even worse.
What I wanted instead
I wanted exception handling to be something applications configured, not something they rebuilt.
The goal wasn’t to replace Spring’s exception handling.
It was to standardize it.
Applications should be able to share:
- a consistent error response
- centralized error codes
- framework integrations
- sensible defaults
- the ability to customize when necessary
Without copying hundreds of lines of infrastructure between repositories.
A modular approach
One design decision became clear very early.
Not every Spring application uses the same stack.
Some applications use Spring Security.
Others don’t.
Some use Spring Data JPA.
Others use MongoDB.
Some don’t even have a database.
So instead of creating one large dependency that tries to handle everything, I chose a modular architecture.
The core library remains lightweight.
Framework integrations live in dedicated modules.
That means applications only add the functionality they actually need.
The latest addition
The newest release expands framework support with built-in integrations for two of the most common Spring technologies.
Spring Security
Authentication and authorization exceptions can now be translated into the same standardized error response used throughout the rest of the application.
No additional exception handlers required.
Spring Data JPA
Persistence-related exceptions are now supported through a dedicated module:
nerv-exception-spring-data-jpa
Keeping JPA support separate means applications that don’t use Spring Data JPA don’t inherit unnecessary dependencies.
It’s a small architectural decision, but one that keeps the library flexible as the ecosystem grows.
The philosophy hasn’t changed
Whenever I add support for another framework, I ask the same question.
Should every application have to implement this itself?
If the answer is “probably not,” it belongs in the library.
The goal isn’t to hide Spring.
The goal is to remove repetitive infrastructure while still feeling like Spring.
What’s next?
I’m continuing to expand the Nerv ecosystem one problem at a time.
Not by building another framework…
…but by extracting the infrastructure I’ve implemented repeatedly across real-world projects into reusable, production-ready libraries.
If you’ve ever copied an exception handler from one project into another, I’d love to hear how you’ve approached it.
I’m always interested in seeing the different patterns teams use.
The latest version of nerv-exception is available on Maven Central.
Source code:
https://github.com/czetsuyatech/nerv-exception
Feedback, ideas, and contributions are always welcome.
답글 남기기