[ http://jira.codehaus.org/browse/CONTINUUM-778?page=comments#action_70162 ] Brett Porter commented on CONTINUUM-778: ----------------------------------------
a couple of thoughts on checked v unchecked: - it's still important to use checked exceptions in reusable apis (in particular to advertise what might go wrong) - it's good to use and handle checked exceptions in recoverable or "graceful error handling" situations. - I'd prefer we have more specific handling, even of fatal errors. "Database down" can present a friendly and helpful error page rather than various varieties of jdo/sql exceptions. I really consider runtime exceptions a last resort (this really shouldn't happen, or I don't know what to do if it does and can't give you enough info to do anything either, so I don't want to proliferate it through the api). > 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
