Hi, everyone.
I'm looking at 2.3 Proposed Final Draft 2.
First of all, there's a flat-out bug in the documentation of the
HttpServlet.service methods (both overloaded versions), in the @throws (or
@exception) Javadoc tag:
java.io.IOException - if an input or output error occurs while the servlet
is handling the TRACE request
javax.servlet.ServletException - if the request for the TRACE cannot be
handled
That said, the reason I was looking at that section is that it is my opinion
that that part of the specification has always been too vague. Generally
speaking, the specification doesn't draw any distinction between those two
exceptions -- the nearest thing to a distinction is in the Javadoc @throws
section for, say, doGet():
java.io.IOException - if an input or output error is detected when the
servlet handles the GET request
javax.servlet.ServletException - if the request for the GET could not be
handled
I think that there's too much overlap between these two definitions. A
servlet container author would, in my view, find it impossible with the
current specification to figure out what the causal distinction was between
a servlet throwing an IOException or a ServletException.
If the purpose of the servlet that the author has written is to deserialize
an object and send it back to the browser in some other format, and the
deserialization fails (say, because of an incompatible class change), the
developer will receive an InvalidStreamException (subclass of IOException),
and may well propagate it back to the container, since there is nothing in
the specification which says otherwise.
Or, to take a another example, consider the canonical 'file' servlet. At
this point, a servlet author might well attempt to retrieve a non-existent
file and pass the FileNotFoundException (subclass of IOException) back to
the container, when it seems to me this ought not be the intent.
Granted, we have IOException and ServletException in the signature and can't
get rid of either. But I think that the specification should be updated in
order to clarify the semantics of the two exceptions.
I would update the description of IOException in javax.servlet.Servlet from:
java.io.IOException - if an input or output exception occurs
javax.servlet.ServletException - if an exception occurs that interferes with
the servlet's normal operation
to
java.io.IOException - if an input or output exception occurs WHILE
ATTEMPTING TO COMMUNICATE WITH THE CLIENT.
javax.servlet.ServletException - if any other exception occurs while
attempting to service the request.
Then I would update the HttpServlet methods (service, service, doXXX)
similarly.
I'd also suggest some sort of clarification as to what circumstances might
even lead to a java.io.IOException being thrown at all. In my view, the only
"legal" IOException should be an IOException that results from a call to
ServletInputStream or ServletOutputStream. Any other IOExceptions (which
necessarily are now application-level exceptions) should be wrapped as
ServletExceptions.
This clarification would allow servlet containers to handle IOExceptions
appropriately. Right now, from a container author's point of view, I believe
that the vagueness of the specification makes IOExceptions and
ServletExceptions indistinguishable. I can't see any reason for a servlet
container author to handle them differently. Clarifying the correct
semantics would allow container authors to handle application-level failures
one way and network-level failures another, which I think would add value.
I think the best long-term solution would be to declare a new subclass of
IOException (ServletIOException?) and make the methods of ServletInputStream
and ServletOutputStream throw -that- exception. Then container authors could
have their error handling routines look like this:
try {
// execute servlet
} catch (ServletIOException e) {
// handle communication error
} catch (IOException e) {
// handle application error
} catch (ServletException e) {
// handle application error
}
Container authors would, I think, have little trouble altering their
implementations of the ServletInputStream and ServletOutputStream classes to
comport with the new restriction. Servlet authors would also have to make no
changes, so far as I can see.
The advantage of this approach would be that servlet authors who
(erroneously, under my proposed specification clarification) have been
propagating IOExceptions back to the caller would "automatically"
have -those- IOExceptions treated as application-level errors, which they
are. However, true communication errors would be detectable by servlet
containers and could be dealt with separately.
David Caldwell
___________________________________________________________________________
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
