[ http://issues.apache.org/struts/browse/SHALE-336?page=comments#action_38771 ] Craig McClanahan commented on SHALE-336: ----------------------------------------
> Should be try wrappering processDecodes, processValidators, processUpdates > and processApplication? I'd like to see us try this ... the mission statement for the exception handling feature should be to grab all possible application-fired exceptions and put them through the process. We've got exceptions from the lifecycle events covered, and the proposal here covers action events. But we should strive for as many use cases as we can. > Exceptions raised in action listeners are exempt from the exception handing > strategy of the view controller. > ------------------------------------------------------------------------------------------------------------ > > Key: SHALE-336 > URL: http://issues.apache.org/struts/browse/SHALE-336 > Project: Shale > Issue Type: Improvement > Components: View > Affects Versions: 1.0.4-SNAPSHOT > Reporter: Gary VanMatre > Priority: Minor > Attachments: view.patch > > > The action listener events are fire by the lifecycle in the invoke > application phase. If an exception is raised, there is not a trap similar to > the ViewActionListener for handling action event invocation exceptions. > In an attempt to make the error handing strategy consistent between the two > types of application callbacks, I propose that we subclass the view root and > override the processApplication method. Within this overridden method, we > trap the exceptions and add them to the exceptions list. > I'm not sure what side effects this might have but I thought it should be > discussed first. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/struts/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
