I think this is a good idea. I also have similar repetative exception
handling in all of my action classes. Having global exceptions to handle
general system errors would be helpful. I might prefer to handle some
"expected" exceptions in my action class just to make the code easier to
read but I could do without having to trap Exception in every action class
and forwarding to a system error page.
Wouldn't Joe Faith's example have to support a forward or path attribute so
the action servlet would know where to forward to?
<action ....>
<exception error="some.error.key" type="package.Exception"
forward="failure" />
</action>
or
<action ....>
<exception error="some.error.key" type="package.Exception"
path="/error.jsp" />
</action>
-----Original Message-----
From: faith [mailto:faith]On Behalf Of Joe Faith
Sent: Thursday, November 01, 2001 5:44 AM
To: Struts Developers List
Subject: Re: Declarative exception handling for Action classes
This looks useful, but would be even more so if you could include the
following type
of exception mapping:
<action ....>
<exception error="some.error.key"
type="package.Exception" />
</action>
The action servlet would then generate an ActionError and add it to the
request.
This would save a lot of code of the following type:
} catch (package.Exception e) {
errors.add(ActionErrors.GLOBAL_ERROR, new
ActionError("some.error.key"));
saveErrors(request, errors);
return (mapping.findForward("failure"));
}
which seems to take up half of my actions at the moment.
Laine Donlan wrote:
> Each action mapping can define any number of exceptions that may occur
> and how they should be handled. The handling of the exceptions
consists
> of the definition of a key value (error message, etc) , and a path
> (optional - input of the action would be the default). When an
> exception occurs that can be handled the ActionException (consisting
of
> key, and path) is placed into the user's session under a key constant
-
> org.apache.struts.action.ACTION_EXCEPTION. It can then be handled
> however is necessary by an app.
> The following would be an example of an action mapping:
>
> <action path="/handleSomething"
> name="someForm"
> validate="false"
> input="/someUri.....">
>
> <forward ...just like always/>
> <exception key="some.key"
> type="some.package.business.logic.Exception"/>
> <exception key="some.other.key"
> type="some.package.business.logic.Exception2"
> path="/someotherUri..."/>
> <exception key="general"
> type="java.lang.Exception"/>
> <exception key="ejb"
> type="javax.ejb.EjbException"
> hierarchachal="false"/>
> </action>
>
> The following outlines how each of the exceptions would be handled:
>
> 1) If an some.package.business.logic.Exception is throw from the
Action
> perform method, the client will be dispatched to the input of the form
> with an ActionException placed into the session under a specific key.
>
> 2) If an some.package.business.logic.Exception2 is thrown, the client
> will be dispatched to the path specified in that mapping with the
> ActionException placed in the session.
>
> 3) If anything other than the previous 2 exception or an EjbException
is
> thrown, the client would be re-directed to the input of the form,
again
> with the ActionException placed into the session.
>
> 4) If an EjbException is thrown (it's children would not be handled by
> this) then the client would be dispatched with that ActionException in
> the session under a defined constant value.
>
> The changes to the code base consisted of:
>
> 1) Addition of ActionException and ActionExceptions classes. Very
much
> like the existing mapping classes.
> 2) Change of the perform() method signature to throw Exception rather
> than IOException and ServletException
> 3) Update the processActionPerform() method of the ActionServlet
perform
> the try{}cactch{} and to map resultant exceptions.
> 4) Add the digesting into the ActionServlet init()
> 5) Add the ActionExceptions reference into the ActionMapping.
>
> I have attached the code:
> <<changes.zip>>
>
> As well as diffs of the changes to the ActionServlet and Action
classes
> <<Action-diff.txt>> <<ActionServlet-diff.txt>>
>
> A couple of major @todo's in the code would be the implementation of
> global-exceptions, and a currently hard-coded exception message in any
> unhandled exception that is wrapped into a ServletException. I wanted
> to see if there was interest for this type of feature, if so I can
> easily put the rest of it together and submit it.
>
> Thanks, any comments or feedback would be appreciated.
>
>
------------------------------------------------------------------------
> Name: changes.zip
> Type: Zip Compressed Data
(application/x-zip-compressed)
> changes.zip Encoding: base64
> Description: changes.zip
> Download Status: Not downloaded with message
>
> Name: Action-diff.txt
> Action-diff.txt Type: Plain Text (text/plain)
> Encoding: base64
> Description: Action-diff.txt
>
> Name: ActionServlet-diff.txt
> ActionServlet-diff.txt Type: Plain Text (text/plain)
> Encoding: base64
> Description: ActionServlet-diff.txt
>
>
------------------------------------------------------------------------
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
Joe Faith
Runtime Collective, Ltd
T: (+44) 01273 234294
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
