Christopher:
You have good points.
A couple of comments:
I assume that the fact that servlet authors are allowed to throw IOException
in addition to ServletException is a historical artifact, which was given to
servlet container authors so that they could simply re-throw any exceptions
that they received writing to the underlying socket connection back to the
caller (who had no prayer of handling them).
You are correct in stating that in principle the container author can
already handle these exceptions differently; I should have thought that
through better.
In terms of "what difference does it make," I was thinking things as simple
as how the message is logged by the container (by default). I wasn't
thinking of the init file exception handling (which, FWIW, I also think is
ugly ugly ugly) ...
An IOException because a user dismissed a file-save dialog, for instance, is
a lot different than one where an application programmer experienced an
IOException somehow. As a practical matter, though, where stack traces in
the logs cause panic, it's annoying to get midnight calls from system
administrators complaining about your application's unhandled exception
which they saw in the log file. Or whatever.
But you're right, if I want to go and write my own servlet container (or
modify my own open-source one), I can fix this stuff to my liking, and I
hadn't carried my thinking through to that point.
-- David.
-----Original Message-----
From: A mailing list for discussion about Sun Microsystem's Java Servlet
API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of
Christopher K. St. John
Sent: Thursday, July 26, 2001 8:31 PM
To: [EMAIL PROTECTED]
Subject: Re: javax.servlet.http.HttpServlet.service() throws clauses
"David P. Caldwell" wrote:
>
> I'm looking at 2.3 Proposed Final Draft 2.
> ...
Since the container is the one handing out IOExceptions from
client streams, it already knows if there's a problem on
that end.
SRV.9.9.2 goes into detail on the semantics of exception
handling. If you want to argue that programming-by-init-file
is an ugly, ugly thing, then I won't disagree, but it seems
pretty clear what the container's responsibilities are.
> Clarifying the correct semantics would allow container authors
> to handle application-level failures one way and network-level
> failures another ...
>
What ways, exactly?
--
Christopher St. John [EMAIL PROTECTED]
DistribuTopia http://www.distributopia.com
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
