>> - As an alternative to passing the exception you are throwing under
>> a particular request or session scope key, how about having your
>> Action simply wrap the business logic exception inside a
>> ServletException (as the root cause) and throw that? The perform
>> method already declares "throws ServletException", and we could
>> enhance the controller servlet to simply do its exception mapping
>> trick on any exception thrown by the perform method.
>This seems like a good idea to me. People who want the "throws
Exception"
>semantics can easily achieve it by subclassing Action and doing a try{}
>catch{} in there, and then having all their actions extend the
subclass.
I guess my thinking here is if the controller is always going to do
something like
try{
}catch(SevletException ser){
....do something with ser.getRootCause()
}
Then why not force the issue of the ServletException and allow for
actions to throw Exception.
If an exception is thrown that has not be mapped to an action, then it
will be wrapped in
ServletException and re-thrown - then it will be available for the
normal <error-page>
type handling by the container.
>> But, given all of the above, if you have your actions throw a
business
>> logic exception wrapped in a servlet exception, is there something
needed
>> that the standard <error-page> mechanism does not handle for you?
The
>> only thing I can think of would be the global/local mapping option
(which
>> is probably a good enough reason to do this), but the standard
mechanism
>> seems to be pretty complete.
I think that the action level granularity is what we will be buying. I
do agree
that the built in error-page functionality could be utilized for the
global type
errors. What would be lost will be the ability to define error keys,
etc.
>Matching exceptions to handlers should check the inheritance
>hierarchy of the actual exception, but trying to match on the
>exact class first. This is how the servlet container (at least
>for version 2.3 and beyond) match up exceptions when you define
>an <error-page> for a particular exception.
This is pretty much how the code submitted would work. The only
difference would be that if the heirarchy has multiple layers, with
multiple exceptions from the
same hierarchy mapped, an exact match cannot be made - the first
exception found from which
the thrown exception could be assigned win the search.
Laine
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
