> - If we pass the actual exception as attributes, I would suggest
> using request scope rather than session scope. This will allow
> the technique to work even in apps that don't use sessions, and
> will also avoid problems when there are multiple simultaneous
> requests for a particular session.
Maybe a "scope" type attribute like we use elsewhere? Since our application
makes heavy use of frames, putting stuff in the request doesn't always work
(at least, not easily).
> - 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.
> 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 guess the difference would be that it can't be configured "per action"
(right?) and its not integrated with struts style error messages from
resources files (correct me if I'm wrong!).
Cheers,
Simon Sadedin.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
