Currently I attempt to catch all exceptions as close to the source as possible and write a detailed error message to the error log, including the class and method name and enough details that I might figure out what actually stuffed up. I then re-throw a ServletException, containing a fairly generic error message (eg. "Unable to process login") and the original Exception (using the 2 parameter constructor). This bubbles all the way from the error source, back through the various layers, which all are defined to throw a ServletException, until it gets to the ActionManager that dispatched the request to the appropriate WebAction class perform method. It then forwards to the standard JSP error page as you described. In my experience with supporting a number of large apps, usually installed 1000kms away with no online access, error detection and logging is absolutely vital. One thing a lot of people seem to get wrong is telling the end-user too much about the problem. It only makes sense to provide them with enough information for them to understand what has become of their requested action and what they should do next. Eg. "Saving your request has failed. This error has been logged with technical support. Please retry your request". Stuff like including a stack trace or more info like "Unable to reset AUTOCOMMIT during transaction" doesn't help them, because they can't use that information to fix their problem (if only!). And you can't rely on users to supply that sort of detailed error to you when they log a support call. So I present the user with something simple and write out heaps to the error log. Regards Drew Cox > -----Original Message----- > From: Damian Fauth [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, January 18, 2000 12:28 PM > To: [EMAIL PROTECTED] > Subject: Re: Providing application resources to action classes > insingle-servlet delegation model > > On the subject of Exceptions in the Model II (MVC) JSP architecture - is > there some recommended way to handle Exceptions thrown within the > controller servlet from the presentation point of view? it seems that > the errorPage > attribute of the <%@ page> tag in the page that the request is forwarded > to is ignored because the Exception is thrown outside of the page > context. > > The only way to use this error page seems to be to wrap the exception in > a JspException, and put it in the request via a setAttribute() method > call and forward to the error page - not pretty. > > Any suggestions? How do others manage Exception handling in Model II? > > Damian > > Slava Kozlov wrote: > > > > BTW, > > > > Since we're writing out interfaces, I recommend that WebActions throw > > WebActionExceptions not (or at least, not only) the lower-level > > ServletException and IOException. The reasons are double-fold: > > > > Encapsulation: > > Depending upon your design (which class processes error code?), > maybe the > > controller servlet shouldn't need to know about low-level details such > as > > when a WebAction was unable to open a file. After all, that's the > > WebAction's business. Let it catch these exceptions and deal with them > and > > only throw the controller exceptions at "its" level. > > > > Extensibility: > > There may be times when a WebAction fails without it being a > Servlet or an > > IOException. There are tons of examples, database not accessible, or > > security problem or, etc. Changing the signature to account for these is > I > > think necessary. > > > > -s > > > > > ========================================================================== > = > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > > FAQs on JSP can be found at: > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.html > > -- > Damian Fauth Fairfax Interactive Network (F2) > Senior Software Engineer 201 Sussex Street > Ph: +61 2 9282 3528 Sydney NSW 2000 > [EMAIL PROTECTED] http://www.f2.com.au > > ========================================================================== > = > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > FAQs on JSP can be found at: > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html =========================================================================== To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". FAQs on JSP can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html
