Re: [Springframework-developer] MVC Exception Handling

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

> > 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.

I agree.

> 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.)

You shouldn't need AOP to do this.

> 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.

This is fine.  Mostly I am looking for behavior / feature.  How it is
implemented is secondary.
I thought of the possibility of doing it that way after sending the e-mail.

> > 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.

Thanks :)

> > 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.
>
Thanks again :)

It sounds like Jurgen may have added the functionality I described above:

> 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.

So does "..including base classes.." mean that it will handle the subclassed
execeptions (instance of or isassignable) as I suggest above?

It sounds as if the capability to have a "default" and "over-ridding"
exception / view mappings has already been added.  : )

I think it would be great if some examples of how to set this up could be
created as well.  You guys are doing an awesome job of adding features /
functionality but I think the documentation is having a more difficult time
of keeping up.

Later
Rob