tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@virgil.nl>
Subject Re: IOException API proposal
Date Wed, 14 Jun 2000 23:17:36 GMT


Eric Hamilton wrote:
> 
> At 11:23 PM 6/14/00 +0200, Mark Brouwer wrote:
> >I have written a rough proposal 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 :-)
> 
> Your proposal does address a real problem, but it's not the right answer.
> Error numbers only work when either there is a single authority controlling
> their assigment (as in errno.h and winerror.h) or when there is no
> polymorphism, so that at runtime you know which authority to consult.  For
>

I don't see the problem, as long as the people in Java Community Process
responsible for the next JDK can agree about a list of common errors
(you can take the ones from UNIX 98 e.g.)

With regard to polymorphism you have a good point, but most of the times
you as a developer knows the context. SocketException subclasses
IOException, but if I'm working with sockets I know I won't get a
'filename too long' (not taling about somebody doing persistent sockets
:-)

>
> example, suppose you and I both write classes that extend java.io.Reader
> (and therefore can throw IOException).  I decide that I will use error
> number 15 to describe a particular error condition.  You, working
> independently of me, decide to use 15 to describe some completely different
> error condition.  Now consider the code fragment:
> 

When I was writing the proposol I also was thinking about this, but I
wiped it out for I was already deviding the long range into blocks of
numbers, etc. :-) But it is obvious you need something 

> java.io.Reader r = getAReaderFromSomewhere();
> try
> {
>     int i = r.read();
> }
> catch( java.io.IOException e )
> {
>     if( e.getErrno() == 15 )
>        doSomethingSensible();
> }
> 
> I submit that it is impossible for doSomethingSensible() to do anything
> sensible  :-)
> 

Well if your reader does something special that can cause exceptions
with error numbers other than those already defined by JDK 'whatever
level' you can refer to your API in which you should specify these
numbers. It is just a matter of keeping clear of the reserved number
space, defined by a standard body.

Also I would suggest using final static fields for referring to error
numbers, like java.io.FileError.NAME_TO_LONG. It would even be nicer to
use 'enumeration' like has been done with Locale, that way nobody could
compare  an error with something non-existent.

> Error numbers cannot be chosen from a single flat namespace for the same
> reasons that Java class names, ASN OIDs, and even DNS names cannot.
>

As with MIME types and so many other identifiers, people have been
succesfull in standardizing a ranges. I know it is a pain to ask for
them, but the real pain is in the errors that are at the system level.
Most of them are standardized .... somewhere
 
>
> What's really needed is for java developers to to be much more aggressive
> about subclassing the existing excepion classes.
> 

In general I agree with you, however if you can get 40 different
exception, I think people start complaining. Do you know how many MB of
JavaDoc you have to download for that :-) But subclassing also mean a
standard body (JCP) should define all these Exceptions and that the
people implementing a JVM should map these on the underlying native
libraries.

An advantage of aggressive subclassing exceptions would be the explicit
declaration of these exceptions. But as their number will be high,
nobody is going to declare these and therefore they just use the common
superclass.

At the end I see no real advantage of subclassing above error numbers,
taken the large number of possibilities in some cases, but minds can
change.

In Java 2 they introduced some more SocketException but that attempt is
just not enough.
-- 
Mark Brouwer

Mime
View raw message