Re: [Springframework-developer] MVC Exception Handling

[Rod J. <rod...@in...>]

Rob

> By having the exceptions handled at the DispatcherServlet all exceptions
are
> handled the same no matter which controller (i.e. place in the web
workflow)
> threw the exceptions.  This is great, if I always want ExceptionXYZ to
show
> the same view.  If you add a similar capability to
> org.springframework.web.servlet.mvc.AbstractController then the view /
> exception mapping could be customized for each.

True, but it definitely makes sense for there to be _one_ default.

It is possible to use an AOP proxy around an individual controller so that
an exception could be caught and replaced by a ModelAndView object also.
Although this mechanism is harder to configure and requires knowledge of
AOP, at least it is possible. (A BeanPostProcessor could make such AOP
configuration easier.)

However, there may be a case for extending the ExceptionResolver behaviour
to individual controllers. How would a controller-specific mapping work?
Couldn't just be known implementations of ExceptionResolver?

If there is an individual mapping, I wouldn't handle it in
AbstractController, but in DispatcherServlet, which knows which Controller
it just used. Then it's not tied to a particular AbstractController.

> When an exception occurs, the mapping in the AbstractController (or sub
> class) would be checked first, if no match was found then the mapping in
the
> DispatherServlet would be checked.  This would allow for "general" view /
> exception mappings to be done in the Dispatcher, while also allowing the
> AbstractController the opportunity to over-ride the more general view /
> exception mappings.
>
> Alternately, you could move the implementation of the Exception mapping to
> the AbstractController, and not have it in the DispatherServlet.  Then any
> exception mappings that are specific to that controller would be added to
> it, and you could have a separate place to declare any that are "global".
> The "global" ones would be added to the end of the ones declared for that
> particular AbstractController.  In this way you would still have the
> "general" view / exception mappings, but the code would only have to be in
> the AbstractController.
But this ties the behavior to AbstractController, thus degrading the
Controller interface and privileging concrete inheritance.

> Also, I hope the ExceptionResolver you implemented will work for both
> checked and unchecked exceptions.  In general, an unchecked exception
would
> just mean "something really bad and uncontrollable happened" to the user,
> but it could be useful to display different error messages to the user
> depending upon what the exception is.  I.E. if my app throws a runtime
> exception because a remote system is down (one that is generally flaky
let's
> say, and you have no control over it - you know, the kind of stuff you run
> into all the time with legacy systems) you may want to tell the user to
come
> back and try again in a few minutes.  But if your database server is down
> and causing you to bubble up unchecked DB exceptions, you may want to tell
> them to come back tomorrow.
Good point.

> Also, it would be great if your ExceptionResolver could not check for
exact
> matches to exceptions, but could check instanceof, or isassignable.  In
that
> way if I have a whole bunch of exceptions that are subclassed from some
> common one, and I want all of them to show the same view, I can simply add
> the base one to the ExceptionResolver, instead of each one subclassed from
> it.  Also, since your ExceptionResolver checks in "order" if I had one to
> two of those subclassed exceptions I wanted handled differently, I could
> register them before the base one.  This would again, allow those to be
> handled specially, and all the others would follow on to the base one.
Good points.

Regards,
Rod