You need two strategies - one for errors you can handle and recover from, and another for everything else.
For errors I can handle (includes exceptions and business-level validations), I describe the problem in plain english, stick it into a string attribute on the request object, then I forward to the previous screen. On each screen I include a messages page which displays these messages as well as any ActionErrors. I also use this for success messages. If you need i18n, a better approach would be to use the ActionMessage instead of strings (but they came along sometime after the 1.0 release). For errors I don't handle, I throw servlet exceptions. At the moment I haven't bothered with an error page, though I intend to set up a page in my web.xml that catches all java.lang.Exception's, displays the error, and provides a button or link to hop back to the start page of the web-app. How is everyone else handling it? - Paul ----- Original Message ----- From: "Greg Callaghan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 28, 2001 1:40 PM Subject: Struts Error Page Approach - Recommended / Struts Support > Hi, > > Wondering what the typical struts approach is to handling and passing back > errors to the user is. I'm not talking about ActionForm validation, but > rather the situation where an Action determines there is a error (ie either > directly itself or via an exception from a business object). > > What is recommended approach with struts? > - use of servlet "errorpage" specified in Web.xml? > (not sure how this works yet, still have to find good doco) > - use of struts "errorpage" as GLOBAL FORWARD to JSP which > assumes maybe a ERROR_MESSAGE in request scope? > - incorporate use of struts validation error infrastruture somehow? > (eg re-use ActionErrors perhaps)? > - would creating an ActionError in the Action itself and forwarding > back to the original JSP page be possible in the case where there > is not normally form validation on this page. ie leverage off > ability to put <html:errors/> in JSP just to handle presentation > of backend errors (ie not formbean validation errors). > > I'm assuming the general approach overall is to throw business logic errors > up the chain until hitting the Action classes so one may then present an > appropriate error message to the user (via one of the approaches above?). > > > cheers > Greg > > _________________________________________________________________ > Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
