Hi! We have a complex web application with lots of JSPs and a considerable amount of servlets for various purposes. Our app runs in Tomcat 5.5 and among other custom error handling techniques we also used the Servlet API mechanism of placing the following directive in our web.xml:
<error-page> <exception-type>java.lang.Throwable</exception-type> <location>/JSP/unhandledJSPError.jsp</location> </error-page> Due to the complexity of our application, it is unpredictable if the unhandled exception occurs before or after the response has already been committed. One example where the exception definitely occurs after the response has been committed is a class that serves download requests. If the user downloads a big amount of data, pressing the cancel button while waiting for the download is normal and must be dealt with in the server application. (Note that i'm using this only as an example, of course the server-side errors that are caused by cancelled user requests can be safely ignored, but this is a totally different discussion outside the scope of this thread.) So, here's what's happening: - user clicks download link - servlet starts writing (say) 100 MB of data to the response - user grows impatient and clicks cancel - servlet encounters a SocketException or similar because it is unable to write further data - while trying to handling the error situation, tomcat calls the reset() method on the response. This causes an IllegalStateException because the servlet has already written and flushed the response. According to the Servlet API, trying to "undo" a response in any way *after* already having written physical data to the HTTP client is a "no-no", hence the IllegalStateException. In this light, it may or may not be OK to actually call the reset() method as is done now (talking of Tomcat 5.5.12) in StandardHostValve.custom(). [Try googling for "StandardHostValve.custom(", the numerous results tell you that this error situation occurs frequently out there...] However, the mechanism of a standard error page is of somewhat meager use for a complex application because, as the scenario above shows, it does only work if the response is "clean" i.e. has not yet been written to physically. We decided to work around this as follows: - Our JSPs will be augmented with a JavaScript redirect to the error page instead of the web.xml error page directive. - Our Struts Action classes will handle all Throwables by redirecting to the error page - Our servlets will handle all Throwables internally So, effectively, no Throwable ever travels outside of the application. (Note of course that browsers w/o JavaScript will probably see an ugly IllegalStateException error instead of our carefully designed error page. Since our app checks that JavaScript is enabled, this is no problem for us.) We're not 100% sure if our approach was actually intended by the Servlet API gurus, so we'd like to know what others think about this and how this issue is dealt with in other nontrivial apps. The most important (and simple) lesson to learn probably is that if your app once has committed data to the client, then it must find a clean method of saying "Oops, sorry, there was a problem" *together* with the already written data. Any other ideas / suggestions? --------------------- Robert Graf-Waczenski LISTSERV Maestro Core Development Team L-Soft Germany GmbH Knowledge is just a click away: http://www.lsoft.com/optin.html --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]