|
From: <jue...@we...> - 2003-11-22 17:16:21
|
Everybody,
=20
Continuing the tradition of last minute changes: I've repeatedly thought =
about exception handling in the web tier, especially when analyzing =
Struts 1.1 and WebWork2. Both of the latter allow an action to throw any =
Exception (Struts 1.0 did not, BTW); Struts additionally supports =
declarative mapping of exception to exception handlers.
=20
Steve, who's mail I've quoted below, has the use cast that all of his =
business methods throw checked exceptions, but our web controllers just =
allow ServletException. Instead of wrapping his exceptions all the time, =
it would be much nicer if our web controllers would allow any Exception =
to be thrown, just like Struts 1.1. and WebWork.
=20
A poster on our forums recently noted that he would like to be able to =
forward to a specific error page if he encounters certain conditions in =
his form controller methods (like referenceData or formBackingObject). =
This is valid concern: Such exceptions effectively exit from the normal =
workflow to a well-known error page within the web MVC framework.
=20
Therefore:
=20
1. I've just changed all our web controller signatures from =
ServletException+IOException to Exception. DispatcherServlet wraps =
Exceptions other than Servlet/IO in ServletExceptions.
=20
2. I've introduced an ExceptionResolver mechanism: DispatcherServlet =
registers all implementors of the interface ExceptionResolver and allows =
them to resolve exceptions to ModelAndView objects, for forwarding to =
specific error pages within the web MVC framework. Of course, =
ExceptionResolvers can be ordered: They get invoked one by one until a =
ModelAndView was returned; if none could resolve the exception, default =
handling applies.
=20
3. I've added a simple implementation of ExceptionResolver that allows =
to map exception names to view names: SimpleMappingExceptionResolver =
(note that by default, no exception resolver is used). Exception names =
can be any part of the exception class or the exception message. An =
"exceptionAttribute" is supported: The exception gets exposed in the =
model under that name, by default "exception".
=20
4. For exiting the workflow to a specific error page, I've introduced =
ModelAndViewDefiningException: If a handler throws that exception, =
passing a specific ModelAndView into its constructor, DispatcherServlet =
will automatically forward to the specified view - without the need for =
an ExceptionResolver! This is handy for known error conditions that lead =
to well-known error pages, to be checked for example at form setup in a =
form controller.
=20
I'm quite keen on introducing this already for M3, as it removes a =
restriction that neither Struts nor WebWork have, and allows for cool =
exception handling strategies :-) Client code should just be affected at =
very specific points if at all: for example, if calling showForm in =
custom handleInvalidSubmit methods, the method needs to throw Exception =
now instead of ServletException - should be straightforward to adapt. It =
is a good thing that we mainly work with template methods: Allowing for =
more exception types to get thrown does not affect client code there.
=20
I'll wait till tomorrow with committing these changes: If there any =
objections or further suggestions, please voice them promptly!
=20
Juergen
=20
________________________________
Von: spr...@li... im Auftrag von =
Steve Gulics
Gesendet: Di 18.11.2003 22:25
An: springframework-user
Betreff: [Springframework-user] MVC Exception Handling
I've been looking at the sample apps and have some
questions on how Spring handles exceptions.
For example, in the Pet Clinic example, if a checked
exception is thrown when
getClinic().storeOwner(owner); is called in
AddOwnerForm I want to go to a specific error page
based on that exception. I guess I could put the call
in a try-catch block and based on the exception I
return the appropriate ModelAndView. The problem with
this approach is its very tedious. Especially since
all our current BusinessDelegates throw checked
exceptions.
Stuts has a clean approach which has the Struts
Action.excute method throw Exception which allows you
to define in the struts-config.xml a handler for the
exception that will control what page to forward to.
For example
<global-exceptions>
<exception
key=3D"some.key"
type=3D"java.io.IOException"
handler=3D"com.yourcorp.ExceptionHandler"/>
</global-exceptions>
See the following url for more info:
http://jakarta.apache.org/struts/userGuide/building_controller.html#excep=
tion_handler
My question is what is the perferred Spring way to
handle these situations? Is it just try-catch blocks?
I understand that the Spring approach is not to use
Checked Exceptions but I cannot control that since all
the business delegates we currently have throw checked
exception and I cannot rewrite them at this time.
thanks,
Steve
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
-------------------------------------------------------
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-user mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-user
|