## Exception Handling in a RESTful Service with `@ControllerAdvice` You are building a RESTful service in Spring Boot. Walk through how you implement **exception handling** for the API: how a thrown exception becomes a well-formed HTTP response, and how you build a **global, centralized error-handling mechanism** using `@ControllerAdvice` so that every controller returns a consistent error contract instead of leaking stack traces or ad-hoc messages. Cover: mapping exception types to correct HTTP status codes, the shape of a consistent error-response body, how validation failures are surfaced, and how you avoid leaking internal details. ```hint Where to start Separate two layers: *local* handling with `@ExceptionHandler` methods inside a single controller, versus *cross-cutting* handling with a `@ControllerAdvice` (or `@RestControllerAdvice`) class that applies to all controllers. The global advice is what gives you one consistent contract. ``` ```hint Design the contract Define a single error DTO — e.g. `timestamp`, `status`, `error/code`, `message`, `path`, and (for validation) a list of field errors — and a deliberate mapping from each exception type to an HTTP status: `400` bad request / validation, `404` not found, `409` conflict, `422` unprocessable, `500` for the unexpected fallback. ``` ### Constraints & Assumptions - Spring Boot / Spring MVC stack (`@RestController` endpoints returning JSON). - The API is consumed by external clients, so error responses must be stable, documented, and must **not** leak stack traces, SQL, or internal class names. - Both expected domain errors (e.g. "order not found") and unexpected errors (NPEs, downstream failures) must be handled. ### Clarifying Questions to Ask - Do clients need a **machine-readable error code** (a stable enum/string) in addition to a human message, for programmatic handling and i18n? - Should the response follow a standard such as **RFC 7807 (`application/problem+json`)**, or a custom in-house schema? - Do we need to **localize** error messages, or is English-only acceptable for now? - What are our logging/observability requirements — should every handled exception be logged with a correlation/trace id? - Are there security-sensitive endpoints where we must deliberately return generic errors (e.g. auth) to avoid information disclosure? ### What a Strong Answer Covers ```premium-lock What a Strong Answer Covers ``` ### Follow-up Questions - How do you handle bean-validation failures from `@Valid` request bodies and produce per-field error messages? - What is the difference between `@ControllerAdvice` and `@RestControllerAdvice`, and when would you scope an advice to specific packages or annotations? - How would you adopt RFC 7807 `problem+json`, and what are the benefits of a standardized error format? - How do you keep authentication/authorization failures from leaking whether a resource or account exists?