Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What's the simplest way to change from exception logging to exception handling in a Spring MVC app?

My Spring MVC app is full of methods that look like this:

@RequestMapping(value = "/foo", method = RequestMethod.GET)
public final void foo(HttpServletRequest request, ModelMap modelMap){
    try{
        this.fooService.foo();
    }
    catch (Exception e){
        log.warn(e.getMessage(), e);
    }
}

Exceptions are caught and logged but not handled otherwise.

The fooService called above does the same thing, never throwing exceptions up to the controller but catching and logging them. So, actually this controller exception code will never get invoked.

What's the best and simplest approach to implement proper exception handling in my app?

like image 525
Peachy Avatar asked Jul 03 '11 19:07

Peachy


People also ask

How many ways can you handle exceptions in Spring MVC?

Before Spring 3.2, the two main approaches to handling exceptions in a Spring MVC application were HandlerExceptionResolver or the @ExceptionHandler annotation.

What is the best way to handle exception in spring boot?

Altogether, the most common implementation is to use @ExceptionHandler on methods of @ControllerAdvice classes so that the Spring Boot exception handling will be applied globally or to a subset of controllers. ControllerAdvice is an annotation in Spring and, as the name suggests, is “advice” for multiple controllers.

How do you handle authentication and exception handling in Spring Boot and Spring MVC applications?

Spring MVC Framework provides following ways to help us achieving robust exception handling. Controller Based - We can define exception handler methods in our controller classes. All we need is to annotate these methods with @ExceptionHandler annotation. This annotation takes Exception class as argument.

How is exception handling done in Spring MVC?

Spring MVC provides exception handling for your web application to make sure you are sending your own exception page instead of the server-generated exception to the user. The @ExceptionHandler annotation is used to detect certain runtime exceptions and send responses according to the exception.


1 Answers

Get rid of all catch statements if all they do is logging carelessly. catch is meant to handle the error, not hide it.

Once all these catches are removed, install one global exception resolver in Spring MVC (1, 2, 3, ...) Simply implement this trivial interface:

public interface HandlerExceptionResolver {
    ModelAndView resolveException(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex);
}

In your exception resolver you might simply log the exception once and let it go as unprocessed (return null), so that error mappings in web.xml will forward request to proper error page. Or you can handle exception yourself and render some error page. AFAIK in simplest case there is no need for register exception resolver, just define it as a Spring bean/annotate with @Service.

Remember, catch the exception only when you know what to do with. Logging is only for troubleshooting, it doesn't handle anything.

BTW this:

log.warn(e.getMessage(), e);

is not only a very poor exception handling, but it is also slightly incorrect. If your exception does not have a message, you will see mysterious null just before the stack trace. If it does, the message will appear twice (tested with Logback):

22:51:23.985 WARN [main][Foo] OMG! - this is the exception message
java.lang.IllegalStateException: OMG! - this is the exception message
    at Foo.bar(Foo.java:20) ~[test-classes/:na]

...sometimes undesirable, especially when exception message is very long.


UPDATE: When writing your own exception logger consider implementing both org.springframework.web.servlet.HandlerExceptionResolver and org.springframework.core.Ordered. The getOrder() should return something small (like 0) so that your handler takes precedence over built-in handlers.

It just happened to me that org.springframework.web.servlet.mvc.support.DefaultHandlerExceptionResolver running prior to my handler returned HTTP 500 without logging the exception.

like image 148
Tomasz Nurkiewicz Avatar answered Sep 21 '22 03:09

Tomasz Nurkiewicz