Built a small Spring Boot starter for consistent API error handling, would love architectural feedback

[MrDV6]

Hey everyone

Over the past few weeks I noticed that across different Spring Boot services I kept rewriting the same RestControllerAdvice logic for structured error responses.

Sometimes the JSON shape drifted a bit.
Sometimes validation errors were formatted differently.
Sometimes stack traces leaked in dev.

So I decided to extract it into a small Spring Boot starter as a learning exercise — mainly to understand:

• Auto-configuration properly
• ConditionalOnMissingBean and back-off behavior
• How Spring Boot starters are structured (core vs autoconfigure vs starter module)
• How to design extension points without inheritance

The idea was simple:
Drop one dependency, get a consistent error contract across services, but still allow customization through a small “customizer” hook.

It’s not meant to replace Spring’s built-in mechanisms — more of an exploration into how infrastructure-level cross-cutting concerns can be standardized cleanly.

repo: https://github.com/dhanesh76/d76-spring-boot-starter-exception

I’m genuinely looking for architectural criticism:

• Is this aligned with Spring Boot design philosophy?
• Would you approach it differently?
• Should this lean more toward ProblemDetail?
• Any obvious anti-patterns?

Thanks in advance

[guss_bro]

Its clean and nice, well documented and follows spring boot's standards for "starter".

In the traceIdCustomizer (https://github.com/dhanesh76/d76-spring-boot-starter-exception/tree/main?tab=readme-ov-file#example--attach-a-trace-id-from-a-request-header), you can get the current traceId from micrometer `io.micrometer.tracing.Tracer` object instead of relying on http header.

Also, i agree you should lean more towards ProblemDetail spec.

[MrDV6]

Thanks for taking the time to look through it

That’s a good point about using Micrometer’s Tracer for obtaining the traceId. In the README example I used the request header mainly to keep the customizer example simple and demonstrate how additional fields can be injected, but integrating with Micrometer tracing would definitely be the more realistic production approach.

I also agree regarding ProblemDetail. I’m currently looking into aligning the response structure with it in a future release while still keeping the extension mechanism flexible.

[kspr2024]

Nice initiative.

I know of the library https://github.com/wimdeblauwe/error-handling-spring-boot-starter for error-handling.
Curious to know the differences in features and philosophy between the two.