[ http://jira.codehaus.org/browse/CONTINUUM-778?page=comments#action_72240 ] Napoleon Esmundo C. Ramirez commented on CONTINUUM-778: -------------------------------------------------------
I think I'd still go for chaining, knowing that http://jira.opensymphony.com/browse/WW-731 has been reported. I hope it gets done soon (but it doesn't matter if it doesn't). We could configure exception handling better by chaining subclasses of ContinuumException to specific actions, which may in turn implement the necessary checking of levels of details. For the meantime, I submitted an ExceptionLoggingInterceptor to serve our purpose. IMHO, using an interceptor would reduce the refactoring needed than if a base class were to be used. I'd be glad to discuss on this further. :) > show internal error page on unhandled exceptions > ------------------------------------------------ > > Key: CONTINUUM-778 > URL: http://jira.codehaus.org/browse/CONTINUUM-778 > Project: Continuum > Issue Type: Sub-task > Components: Web interface > Affects Versions: 1.0.3 > Reporter: Carlos Sanchez > Assigned To: Napoleon Esmundo C. Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-778.patch, error-mapping.patch > > > It's possible to setup a servlet filter or something similar that maybe > webwork already has (Struts has it) to catch all unhandled exceptions, log > them to the log file and redirect the user to a "internal error" page. > Related to this we should make ContinuumException a RuntimeException, don't > catch it in the web layer and let the previous mechanism do it. We'll save a > lot of exception handling code not needed. > Note that this is only for system exceptions, eg. if database is down, and > not model exceptions, eg. when looking up by id it the record doesn't exist. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
