Re: [Springframework-developer] MVC Exception Handling

[Rob B. <rob...@ve...>]

Jürgen,

Excellent addition...  How about taking it one step further?

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.

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.

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.

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.

What do you think?
Later
Rob