Question

Using Spring 3, I like to create an exception handler using the ExceptionHandler annotation that will handle “no page found (404)” requests. I am using the following code to do this. But when I point to a URL that does not exist, the default exception handler defined by Spring is being invoked.

It might be that I’m handling the NoSuchRequestHandlingMethodException exception. If it is, then what exception should I be registering?

Will you please take a look at the following code and see what I’m doing wrong?

NOTE: If I change the exception in the @ExceptionHandler to NullPointerException and create a RequestMapping to throw null pointer, that will work.

    import org.springframework.stereotype.Controller;
    import org.springframework.web.bind.annotation.ExceptionHandler;
    import org.springframework.web.bind.annotation.RequestMapping;

    import org.springframework.web.servlet.mvc.multiaction.NoSuchRequestHandlingMethodException;

    import org.apache.commons.logging.Log;
    import org.apache.commons.logging.LogFactory;
    import org.springframework.web.servlet.ModelAndView;

    @Controller
    public class GeneralHandler {
      private final Log logger = LogFactory.getLog(getClass());

      @ExceptionHandler(NoSuchRequestHandlingMethodException.class)
      public ModelAndView handleException (NoSuchRequestHandlingMethodException ex) {
        ModelAndView mav = new ModelAndView();
        logger.error("Exception found: " + ex);
        return mav;
      }
    }

Answer 1

@ExceptionHandler-annotated methods are invoked when a @RequestMapping method on that same class throws an exception. So when you added the mapping which threw the NullPointerException, that worked, since the mapped method and exception handler were together in the same class.

When no mapping is found, Spring has no way of associating the NoSuchRequestHandlingMethodException with your @ExceptionHandler, because it didn’t get as far as matching the request to a handler method. This isn’t mentioned explicitly in the docs, but is the behaviour I’ve observed.

If you want to handle this exception specially, you’re going to have to use the more general HandlerExceptionResolver approach, rather than the more specialised @ExceptionHandler technique.