[2397] in java-interest
Re: throws declataration in Java/beta
daemon@ATHENA.MIT.EDU (Gary Aitken)
Sat Sep 30 08:33:44 1995
Date: Thu, 28 Sep 1995 13:06:12 -0700
From: garya@village.org (Gary Aitken)
To: tball@alapa@sun.com (Thomas Ball), garya@village.org
Cc: java-interest@java@sun.com
In-Reply-To: <9509281648.AA14158@alapa.Eng.Sun.COM>
On Thu, 28 Sep 1995, tball@alapa@Sun.COM (Thomas Ball) wrote:
>> >> >It is very important to realize that a Java class is a guaranteed interface.
>> >> >If an method is declared to throw a certain set of exceptions than there is no
>> >> >way a sub class can change that. At first this may seem restrictive, but after
>> >> >a while you will realize that it is wonderful to have this guarantee.
>> >>
>> >> It's not clear to me what's so wonderful about this guarantee.
>> >> There is no similar guarantee that a subclass will not compromise the intended
>> >> behavior of its base in numerous other ways. What makes exceptions special?
>> >
>> >Exceptions affect the control flow of the caller. While implementing
>> >this feature we found a number of bugs in HotJava were we simply didn't
>> >realize that a certain exception could thrown.
>>
>> In other words, because the particular piece of code you were working on
>> did not properly handle all the possible exceptions in the code it called,
>> and this caused some (understandable :-)) debug problems, the decision was
>> made to disallow throwing an exception of a different type.
>>
>> This seems like the wrong approach. Wouldn't it be much more useful to
>> require the equivalent of a C++/C switch stmt "default" catch clause in
>> all exception situations? That would allow for a subclass to throw and
>> catch additional exceptions, and also require that the caller be prepared
>> to at least be made aware that some unforseen exception has occurred and
>> was not handled.
>
>You forget, Gary, that all exceptions are subclassed from Exception.
>It's quite acceptable to have multiple catch blocks going from more
>specific to least, as in:
>
> try {
> Socket s = new ServerSocket(port, 10).accept();
> DataInputStream in = new DataInputStream(
> new BufferedInputStream(s.getInputStream()));
> String ln;
> while ((ln = in.readUTF()) != null) {
> ...
> }
> } catch (UTFDataFormatException utfe) {
> // very specific: client failure?
> } catch (IOException ioe) {
> // somewhat specific: connection problem?
> } catch (Exception e) {
> // generic: unknown exception
> e.printStackTrace();
> System.exit(1);
> }
>
>Essentially, the "catch (Exception e)" is your default catch phrase.
Correct. So... once again, if one requires that the try clause include
a catch (Exception e) default, why prevent a subclass from throwing
other exceptions?
I thought one of the original justifications was that this could somehow
change the control flow in a radically unexpected manner. However, I don't
see how that is much worse than a subclass overriding an exception which
the base class was handling, and doing something radically different with it.
If the former is a security hole, the latter certainly is as well.
Gary Aitken garya@village.org
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
