[ http://jira.codehaus.org/browse/CONTINUUM-778?page=comments#action_70180 ] Brett Porter commented on CONTINUUM-778: ----------------------------------------
well, yes, that is true, but you still need the proper level of detail in the exception to determine what it is, and it can be helpful to display something different to the "user": - the user might be the administrator, so they probably don't want a cryptic "error occurred" and then have to dig in logs (isn't that how this issue was raised in the first place?) - the user might be the one to contact the administrator, so if you can give them more info to help identify the error, then that's better. Anyway, you get the point regardless of the specific example - I'm just saying we should do as much handling as possible rather than tossing everything that goes wrong out to a catch-all. > 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 > Fix For: 1.1 > > > 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
