The message shows up so that <html:errors/> displays it.
Or to put it another way
<html:messages id="message" message="false">
<font color="red">${message}</font><BR>
</html:messages>displays it while
<html:messages id="message" message="true">
<font color="red">${message}</font><BR>
</html:messages>doesn't. So it looks like the exception is generating an ActionErrors object.
I generated an sql error for testing which throws a RuntimeException.
What am I missing??
mas
Joe Germuska wrote:
At 3:11 PM +0200 4/24/05, Sébastien GALLET wrote:
Hello, I'm looking for a good way to manage exceptions in struts. Any links in your bookmarks ?
That's a pretty general question!
I usually start by having a single global exception handler defined which catches anything thrown by Struts:
<global-exceptions> <exception key="GlobalExceptionHandler.default" type="java.lang.Exception" path="/ErrorPage.jsp" handler="org.apache.struts.action.ExceptionHandler" /> </global-exceptions>
This ensures that any exceptions get handled by my app instead of the servlet container. The value for "key" points to a message key in your message resources; mine usually says something like "An unexpected error occurred."
When it catches exceptions, he default Struts ExceptionHandler (as configured above) does three things:
* Puts the exception into the request scope under they key "org.apache.struts.action.EXCEPTION"
* puts an ActionMessages object into the request scope (by default) or the session scope (if the "scope" attribute of <exception> is set to "session"). This ActionMessages contains a single ActionMessage which is created in one of two ways:
- If the caught exception extends o.a.s.util.ModuleException, that type's getActionMessage method is called
- otherwise, a new ActionMessage is created using the "key" attribute of the <exception> config and passing the exception in as the single
* Forwards control to a view renderer in one of two ways:
- If the "path" attribute of <exception> is specified, the forward goes there
- otherwise, the "input forward" for the current request is used.
and forwards control to the path specified in the exception-config (above, "/ErrorPage.jsp") If the Exception which is caught extends org.apache.struts.util.ModuleException, then that class's "getActionMessage" method is used to populate the ActionMessages which is going into the request; otherwise, the "key" from the exception-config mapping is used to create a new ActionMessage, and the thrown exception is included as a message format argument.
So, this basic approach covers at least a way to present users with a page which looks like it belongs in your application, as opposed to a generic container error page; then if you want to provide multiple mappings (either global or per-action-mapping), you can refine this general strategy. You can also extend ExceptionHandler and introduce your own error logging behavior or other specialized operations.
Hope this helps, Joe
-- Mark Shifman MD. Ph.D. Yale Center for Medical Informatics Phone (203)737-5219 [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
