On Thu, 1 Nov 2001, Simon Sadedin wrote:
> Date: Thu, 1 Nov 2001 15:59:28 -0500
> From: Simon Sadedin <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: Struts Developers List <[EMAIL PROTECTED]>
> Subject: Re: Declarative exception handling for Action classes
>
> > - 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).
That makes sense. I would still lobby for request scope as the default.
One thing I didn't comment on before -- do we really need more than one
key, or can we just use a single well-know key name?
>
> > - 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!).
Being able to do mapings per-Action would definitely be a reason to do
this inside of Struts (container managed exception pages are global to the
app). I would suggest we support the "global and local" mappings for
this, just like we do with ActionForwards.
With regards to integration, the container-managed approach would easily
integrate, because it does create a request-scope attribute containing the
actual exception for you. So it would be possible to integrate either
way.
>
> Cheers,
>
> Simon Sadedin.
>
>
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
