Re: [Springframework-developer] MVC Exception Handling

[<jue...@we...>]

I've just committed the exception handling change. The =
HandlerExceptionResolver interfaces can now decide to return a =
ModelAndView based on the exception and the handler object that was =
executed.
=20
A SimpleMappingExceptionResolver allows to map fully qualified exception =
class names (including base classes) to view names, restricting its =
mappings to a certain list of handlers to be set as bean references to =
the "mappedHandlers" property. Multiple resolver instances can thus =
define distinct mappings for different handlers. A generic one without =
mapped handlers can be the last in the ordered chain, providing fallback =
resolution.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 23.11.2003 10:10
An: spr...@li...
Betreff: Re: [Springframework-developer] MVC Exception Handling



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




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer