I haven't played directly with this code yet, but the general concept
sounds very cool. A couple of thoughts:
- 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.
- 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.
- 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.
- Given the change to just having your action throw the exception,
defining global exception handlers with local overrides can be
done in a manner similar to the way global forwards are defined
with local overrides.
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.
Craig McClanahan
On Wed, 31 Oct 2001, Laine Donlan wrote:
> Date: Wed, 31 Oct 2001 22:06:06 -0500
> From: Laine Donlan <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Declarative exception handling for Action classes
>
>
> Wanted to submit the following code for comment from the Struts dev
> group. Being faced with a pretty large development project and a
> development environment that oftentimes had one developer working on the
> Web tier code (Struts) and another developer working at the middle tier
> level (EJB's), an attempt was made to alleviate the need to update
> action code and workflow to accommodate changes in the web tier/middle
> tier contract.
>
> Specifically this related to how business logic exceptions were defined
> and handled. We have found that within our Struts actions we often see
> large amounts of business logic exception handling which usually does
> nothing more then configure a message and forward the user to some kind
> or error url or back to the previous page with a validation type error
> message. Not only is this verbose and repetitious, but it is fragile to
> changes in the middle tier since every time a new exception is added, a
> struts-knowledgeable person needs go into all the struts code and add
> exception handling for it. As with other repitious and tedious code,
> our feeling was that the best way to handle this was to allow for
> exception handling to be declarative and configurable through the
> struts-config.xml. We have therefore created a scheme where exceptions
> are treated much the same as forwards in the current Struts code-line.
> 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.
>
> Exception hierarchies are supported just as they would be in a typically
> try{}catch code block through an optional mapping parameter to determine
> whether or not to support the hierarchy. When attempting to match and
> handle an exception first a specific match would be sought, if one could
> not be found, then a search for any assignable exception would be made.
> The first match would end the search.
>
> 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.
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
