DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5244>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=5244 Declaritive Exception Handling Summary: Declaritive Exception Handling Product: Struts Version: Unknown Platform: All OS/Version: All Status: NEW Severity: Enhancement Priority: Other Component: Controller AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Specifically this relates to how business logic exceptions are 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 Action class now has multiple extension points. I have added an execute() method with the same signature as perform() only that it throws Exception. The default perform() implementation attempts to call the execute() method and if an exception occurs - it is used as the root cause of a ServletException. This was added to allow for the use of try{}catch(Exception ex) semantics with actions and exception handling and alleviate the need to have any exception handling in Action implementations while at the same time provided reverse compatibility with all previously developed exceptions. The ActionServlet will attempt to handle any ServletException that is thrown from a perform() method. It uses the root cause of the exception and searched first the Action's exception mappings and then a set of optional global exceptions for handling. The default handling is to create an ActionError object and place it in the user's session or request (based on scope of exception) using the ACTION_EXCEPTION_KEY value. This handling is isolated in a handleErrorForException method to allow this handling to be easily customizable by ActionServlet descendants. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
