Spring Boot error handling and API response design

spring-boot-core's baseline conventions already state the headline rule (@RestControllerAdvice + ProblemDetail, resolution order, the Spring-Security-filter-chain gap) — this skill is where the full pattern lives: the exception hierarchy, the status-mapping table, validation error formatting, and the response-shape decisions that come up on every real API. Read spring-boot-core's summary first if this is a first pass; load this skill when actually building or auditing the error-handling layer itself.

Why centralize at all

Per-controller try/catch scatters the same mapping logic across every endpoint and drifts out of sync — one controller's UserNotFoundException returns a different shape than another's. A single @RestControllerAdvice class is the one place that decides "this exception → this status → this body," so every endpoint's error path is consistent without each controller knowing anything about HTTP status codes.

RFC 7807 ProblemDetail — the response shape

ProblemDetail is Spring's built-in implementation of RFC 7807, available since Spring Framework 6 and the default recommended shape for this skill set's APIs: