tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <>
Subject IOException API proposal
Date Wed, 14 Jun 2000 21:23:31 GMT

There are some aspects in Tomcat related to IOException handling that
need some improvement. 'Broken pipe' and 'Software caused connection
abort' comes to mind. They are the result of the fact that within Java
it is very hard to find out the actual reason of an exception, taken
into account the only reason you will get is locale and platform

It is very hard to improve the exception handling if you have to take
the locale and platform into account. IMHO I think the Java API should
provide more information. Therefore I have written a rough proposol for
the next JDK release and before sending it off, I thought well lets have
a second opinion by some people doing a lot of exception handling :-)

In the mean while for Tomcat we could create an IOException mapper
capable of translating messages (locale and platform dependent) to
standard error numbers, these we can use in the exception handling. I
think within time this class will grow as more nasty things will bubble
up during field testing, at least its my experience the nasty ones will
always show up here.

-- draft proposol to JSR-000059

By building distributed applications directly on top the 'high' level
API's for networking I have found one particular weak aspect of Java.

As soon as something IO related breaks you have minimal information
about what really is causing the problem. The only information you can
get is by calling the getMessage() method on an exception. Considering
the message is dependent on the underlying OS and the locale used, its
is almost impossible to base decisions on that message and therefore
most developers will treat every particular type of Exception the same

As a result it is almost impossible to bring a distributed Java
application at the same robustness level as you could do with a native
implementation, for you have to be (a) too conservative (act like
everything is fatal) or (b) too optimistic (nothing is really fatal, so
just go on, see where you end).

To solve this problem I propose an addition to the
classes in combination with some general classes defining the error
numbers, e.g. one for Files, Sockets, etc. As most (if not all) errors
are generated by native code it is up to the JVM implementation to make
the mapping between the native error codes and the Java defined ones.

Add to the API:

     * Constructs an IOException with a specified error message
     * and number.
     * @param s error message
     * @param errno error number as specified in .....
    public IOException(String s, long errno);

     * Return error number as defined in ....
     * @return error number or -1 if not set
    public long getErrno() {};

View raw message