Continuum

ContinuumException can't be a RuntimeException. Perhaps we can split it in two classes, a normal exception and a runtime

For exception handling:
http://forums.opensymphony.com/thread.jspa;jsessionid=apk1X_F1tR998Gv1cY?messageID=34547&#34547
http://wiki.opensymphony.com/display/WW/Exception+Interceptor
http://wiki.opensymphony.com/display/WW/Exception+Handling

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).

i don't think you want to show a "database is down page", you show an "internal error" and log the exception to the logs for the administrator, not for the user

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.

Struts has this http://www.onjava.com/pub/a/onjava/2002/10/30/jakarta.html

Webwork provides exception handling:

http://www.opensymphony.com/webwork/wikidocs/Exception%20Handling.html

After following the above link, I'm having a 'Element type "global-exception-mappings" must be declared.' error. Then I checked on http://www.opensymphony.com/xwork/wikidocs/Configuration.html – <global-exception-mappings/> is not there for configuration.

I just found out that the dtd the webapp is using doesn't support <global-exception-mappings/>. I changed it to 1.1.1, which the webwork 2.2.2 the webapp uses, but I still get that error.

Oh, I got that dtd thing working now. The dtd line should be <!DOCTYPE xwork PUBLIC "-//OpenSymphony Group//XWork 1.1.1//EN" "http://www.opensymphony.com/xwork/xwork-1.1.1.dtd">

hi nap

carlos mentioned you were working on this issue, I was fiddling around on trunk and came up with this

not sure where you are on it but this was what I came up with in a few minutes, I tested it by just forcing an exception out of an action I was working with.

You want to show the error page on any Exception (Throwable maybe?) and not show the exception message, but a "contact the administrator" message

applied on trunk

Hello Jesse,

I'm in the point of experimenting chaining the exception handling from the interceptor to an action that would log the detailed messages into the logger and redirect the view to a user-friendly jsp page. But so far, I can't access the value stack from the action, so for now the catch-all solution would be fine--the patch you submitted. I'm attaching a small patch tweaking some stuff in the same issue and continue with the chained handling.

The continuum-webapp currently throws Exception, ContinuumException and ContinuumInitializationException but handles only the last two. The patch just added Exception in the mapping.

I recently added a new baseclass in place of the PlexusActionSupport class on the trunk that does the initialization check that used to be on 1.0.3 where every page had a check to see if the continuum instance was initialized, and if it wasn't to redirect to the configuration edit screens...

perhaps instead of chaining the exception itself from whatever action throws it, we could just add a method to that ContinuumActionSupport baseclass that logs the exception to the logger and then throw the exception normally for the exception interceptor to do its business...

just a thought

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.

CONTINUUM-778-2.patch provides the support for chained exception handling. Chaining the exceptions to actions will enable the checking of levels of details to show to the resulting page. The ExceptionLoggingInterceptor would have to deal with server logs in the meantime.

Applied the patch with changes:

• no need to redirect to an action on error, in fact it can cause infinite loop if the error is in webwork
• no need to separate two types of exceptions, at least for now
• use already existing error.jsp
• moved the exception logger interceptor to plexus-xwork integration as it can be used elsewhere
• files without license header