Return-Path: Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 60155 invoked from network); 2 Nov 2000 17:39:52 -0000 Received: from unknown (HELO nxedge.net-linx.com) (208.38.2.17) by locus.apache.org with SMTP; 2 Nov 2000 17:39:52 -0000 Received: from [208.38.2.10] (HELO ethanw) by nxedge.net-linx.com (CommuniGate Pro SMTP 3.3) with SMTP id 483675 for tomcat-dev@jakarta.apache.org; Thu, 02 Nov 2000 10:39:16 -0700 From: "Ethan Wallwork" To: Subject: RE: Hello? Anybody? Date: Thu, 2 Nov 2000 10:38:53 -0700 Message-ID: <000301c044f3$c4741ee0$d5a0a8c0@ethanw.pre-print.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Importance: Normal In-Reply-To: <764CA2FF49EC054BA086FC8253A52DD74331FD@merc09.us.sas.com> X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N Thank you for responding! The PageContext.handleException() is for handling unhandled page level exceptions. It is declared as throwing ServletException and IOException. The Tomcat implementation calls the errorPage if there is one, otherwise it wraps the exception in a ServletException and throws it. This exception will then eventually get thrown out of the generated JSP servlet's service() method. I have no problem with this behavior. The issue is with what happens when a ServletException gets thrown out of the service() method of a servlet. Currently Tomcat always catches this exception and tries to do something with it. If you have specified an error page in the web.xml file it calls that, otherwise it calls the default one. Under normal circumstances this is the best it can do, but when the call has been made by a RequestDispatcher that is not the case. As it turns out, our application would be able to recover nicely from a situation where the included servlet failed, but there is no way for it to find out. This kind of control is important when generating pages that need to be perfectly formed (such as WML). Since the spec implies that exceptions should be thrown from a RequestDispatcher call rather than handled, and there seems to be nothing in the spec that forbids this behavior, I would like to see it implemented this way. Does anyone know of any reasons it shouldn't be done this way? -- Ethan -----Original Message----- From: Larry Isaacs [mailto:Larry.Isaacs@sas.com] Sent: Thursday, November 02, 2000 8:03 AM To: tomcat-dev@jakarta.apache.org Subject: RE: Hello? Anybody? Hi Ethan, I was hoping that someone more experienced would respond. I am looking at an issue related to servlets throwing UnavailableExceptions which is impacted by the tendency of Handler.java and ServletWrapper.java to eat exceptions. As a result, I've been trying to reach an understanding of how exceptions should be handled in these files. I am not an "expert" on the Servlet and JSP specs, so I'm not sure if there is unwritten intent in the spec that just isn't visible. My "strict" interpretation of 8.5 is that it only requires that any exceptions propagated back must be ServletExceptions or IOExceptions. It doesn't appear to mandate that all or any exceptions be propagated back. The lack of a mandate is a little more apparent with JSP. PageContext's handlePageException method appears to be what JSP generated servlets are expected to call for unhandled exceptions. The API documentation for handlePageException says that if no error page is specified, it should perform "some implementation dependent action." It also doesn't require any exceptions be throw back to a caller if present. Thus, I'm not convinced that Tomcat's handling of exceptions for RequestDispatcher forwarded or included servlets and JSPs is out of spec. Others, please correct me if I'm wrong or missed something. I work mostly on an IDE, and haven't spent much time developing real web applications. For handling something like this, my guess is that you would specify (s) in your web.xml that direct the exceptions to an error handling servlet to deal with them. Cheers, Larry -----Original Message----- From: Ethan Wallwork [mailto:ethan.wallwork@net-linx.com] Sent: Wednesday, November 01, 2000 11:58 AM To: tomcat-dev@jakarta.apache.org Subject: Hello? Anybody? Can someone PLEASE respond on this? Even if only to tell me I have no idea what I'm talking about? I really would like to find out what the proper behaviour for Tomcat in this situation is. Thank you, Ethan -----Original Message----- From: Ethan Wallwork [mailto:ethan.wallwork@net-linx.com] Sent: Monday, October 30, 2000 10:31 AM To: tomcat-dev@jakarta.apache.org Subject: RE: BugRat Report #213 has been filed. Has anyone looked at this? It is a real problem for us, and if others agree it should be changed I will get started on a fix. -- Ethan -----Original Message----- From: BugRat Mail System [mailto:tomcat-bugs@cortexity.com] Sent: Wednesday, October 04, 2000 2:13 PM To: tomcat-bugs@cortexity.com Subject: BugRat Report #213 has been filed. Bug report #213 has just been filed. You can view the report at the following URL: REPORT #213 Details. Project: Tomcat Category: Bug Report SubCategory: New Bug Report Class: swbug State: received Priority: medium Severity: serious Confidence: public Environment: Release: 3.1, 3.2 JVM Release: any Operating System: any OS Release: any Platform: any Synopsis: RequestDispatcher does not propagate errors Description: If a servlet uses a RequestDispatcher to forward or include a second servlet (or JSP), and the second servlet throws and exception from it's service method, that exception is not propagated to the first servlet. This is a problem if you have a setup (like ours) where a single "master" servlet includes a particular JSP depending on thing other than just the request URI, and you want it to be able to handle the errors. As it is, the error gets handled by Tomcat (using default error page, or whatever error page you've configured in the JSP or web.xml file) and the main servlet never knows anything went wrong. In Tomcat 3.2, the RequestDispatcher forward/include methods call the Handler service method. This service method never throws an exception. In Tomcat 3.1 it calls the ServletWrapper handleRequest method, which also never throws and exception. The reason I think exceptions should be propagated is because of section 8.5 of the servlet spec, which strongly implies it: 8.5 ERROR HANDLING Only runtime exceptions and checked exceptions of type ServletException or IOException should be propagated to the calling servlet if thrown by the target of a request dispatcher. All other exceptions should be wrapped as a ServletException and the root cause of the exception set to the original exception. --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org