Controller Advice in Spring MVC

Controller advice centralizes cross-cutting MVC behavior for multiple controllers, most commonly exception handling, but also data binding and model setup. `@RestControllerAdvice` is the REST-oriented form that combines controller-advice semantics with response-body handling.

`@ControllerAdvice` is a Spring MVC component used to apply shared behavior across selected controllers. Its most common use is defining `@ExceptionHandler` methods once instead of repeating them in every controller. By default, advice can participate in processing for controllers across the application, while annotation attributes can restrict which controllers it targets.

An `@ExceptionHandler` method inside advice handles exceptions raised during controller processing when that handler is applicable. The handler can return a response object, `ResponseEntity`, or another MVC-compatible result. With `@RestControllerAdvice`, response-body semantics are applied to the advice methods, which is convenient for JSON or other serialized API error responses.

Controller advice can also contain `@InitBinder` methods for shared binder configuration and `@ModelAttribute` methods for adding model attributes to controllers. These features are useful when multiple controllers need the same MVC configuration, but they should not be used merely because code happens to be reusable; ordinary service components are usually a better fit for business logic.

Advice can be narrowed using selectors such as `basePackages`, `basePackageClasses`, `assignableTypes`, and `annotations`. If multiple exception handlers could apply, Spring's exception-resolution rules and advice ordering determine which handler is selected, so overlapping advice should be designed carefully.

A typical REST application uses controller advice to translate domain or application exceptions into consistent HTTP responses. This keeps controllers focused on request handling while establishing a uniform error contract at the MVC boundary.

Key points

• `@ControllerAdvice` provides cross-controller MVC behavior.
• `@RestControllerAdvice` adds response-body semantics suitable for REST APIs.
• `@ExceptionHandler` is the most common advice feature for centralized exception handling.
• `@InitBinder` and `@ModelAttribute` can provide shared MVC binding and model behavior.
• Advice can be scoped to particular controllers with selector attributes.

Interview questions

What problem does `@ControllerAdvice` solve in Spring MVC?

It provides a central place for MVC behavior that would otherwise be duplicated across controllers. A common example is translating exceptions into consistent HTTP responses. It can also contain shared `@InitBinder` and `@ModelAttribute` methods. This keeps individual controllers focused on handling their requests.

What is the difference between `@ControllerAdvice` and `@RestControllerAdvice`?

`@RestControllerAdvice` is the REST-oriented variant of controller advice. It combines `@ControllerAdvice` behavior with response-body semantics, so handler return values can be serialized as response bodies. `@ControllerAdvice` by itself does not automatically make every handler response a response body. For JSON APIs, `@RestControllerAdvice` is commonly used for centralized error responses.

How does `@ExceptionHandler` work inside controller advice?

An `@ExceptionHandler` method declares which exception types it can handle. When a matching exception occurs during MVC request processing, Spring's exception-resolution mechanism can select that handler from applicable advice. The method can produce an MVC response such as a `ResponseEntity` or a serialized response body. Multiple handlers and advice components require attention to specificity and ordering.

How can controller advice be restricted to particular controllers?

`@ControllerAdvice` supports selectors such as `basePackages`, `basePackageClasses`, `assignableTypes`, and `annotations`. These selectors let an application apply shared MVC behavior only to a chosen controller set. This is useful when different API areas require different exception contracts or binding rules. The narrower scope can also prevent unrelated controllers from receiving behavior unintentionally.

Where should business logic live if controller advice needs to perform substantial work?

Controller advice should generally coordinate MVC concerns rather than become a business-logic layer. If handling an exception requires substantial domain or application processing, that logic should normally live in an appropriate service or domain component. The advice can then translate the result into an HTTP representation. This separation keeps web-specific behavior at the MVC boundary.