Ethan Wallwork wrote:
> 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?
>
My understanding of the spec is that a ServletException or IOException that is
thrown by a servlet included (or forwarded to) by a RequestDispatcher should be
propogated up to the calling servlet. Any other exception (like
IllegalStateException, NullPointerException, etc.) that the included/forwarded
servlet throws should be wrapped in a ServletException, and that exception should
be thrown. This is the way 4.0 works.
If 3.2 doesn't do this, IMHO that is a bug.
>
> --
> Ethan
>
Craig McClanahan
>
> -----Original Message-----
> From: Larry Isaacs [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 02, 2000 8:03 AM
> To: [EMAIL PROTECTED]
> 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 <error-page>(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:[EMAIL PROTECTED]]
> Sent: Wednesday, November 01, 2000 11:58 AM
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]]
> Sent: Monday, October 30, 2000 10:31 AM
> To: [EMAIL PROTECTED]
> 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:[EMAIL PROTECTED]]
> Sent: Wednesday, October 04, 2000 2:13 PM
> To: [EMAIL PROTECTED]
> Subject: BugRat Report #213 has been filed.
>
> Bug report #213 has just been filed.
>
> You can view the report at the following URL:
>
> <http://znutar.cortexity.com:8888/BugRatViewer/ShowReport/213>
>
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
