Consider a Spring Boot controller that throws a MethodArgumentNotValidException. How does ResponseEntityExceptionHandler respond by default?
Think about what HTTP status code is appropriate for invalid input.
ResponseEntityExceptionHandler provides built-in handling for common exceptions like MethodArgumentNotValidException. It returns a 400 status with details about what validation failed.
Which method signature correctly overrides handleHttpMessageNotReadable in a class extending ResponseEntityExceptionHandler?
Check the exact parameter types and access modifier in the superclass method.
The method to override uses protected access and HttpStatusCode for the status parameter in Spring Boot 3+. The exception type must be HttpMessageNotReadableException.
You created a class extending ResponseEntityExceptionHandler and annotated it with @ControllerAdvice. But your custom handleMethodArgumentNotValid method is never called. What is the most likely cause?
Check method signatures carefully when overriding methods.
Overriding methods must match the exact signature of the superclass method. If the signature differs, the method will not override and will not be called.
When a controller receives a request with an unsupported media type, and ResponseEntityExceptionHandler handles HttpMediaTypeNotSupportedException, what HTTP status code is returned by default?
Think about the meaning of the status codes related to media types.
The HttpMediaTypeNotSupportedException is handled by returning 415 status code, which means the media type is not supported by the server.
In Spring Boot, what is the main advantage of extending ResponseEntityExceptionHandler in your @ControllerAdvice class compared to only defining @ExceptionHandler methods?
Think about what ResponseEntityExceptionHandler already implements for you.
Extending ResponseEntityExceptionHandler gives you ready-made handlers for many exceptions like validation errors, media type errors, etc. This saves you from writing repetitive code.