[2036] in java-interest
Re: throws declataration in Java/beta
daemon@ATHENA.MIT.EDU (Jim.Graham@Eng.Sun.COM)
Fri Sep 22 06:50:27 1995
Date: Thu, 21 Sep 1995 12:06:20 -0700
To: pambrose@weblogic.com, dufourd@enst.enst.fr
Cc: java-interest@java.Eng.Sun.COM
From: Jim.Graham@Eng.Sun.COM
The idea behind the declared exceptions is that the list of exceptions
that can be thrown is now part of the API for a method. Previously
there was very little documentation on which exceptions could be thrown
by which methods, and no guarantee that you could trust the
documentation in the first place.
> >This means that you can NEVER throw an exception from a
> >toString() method because Object.toString() doesn't throw
> >any exceptions.
This is true. The advertised API for toString indicates to anyone who
calls it that they can expect that this method will not throw an
exception. And why should it? You are allowed to return any string
you want, but you are not allowed to throw an exception. This way
"System.out.println(obj)" is always safe.
> This is my experience too, and this language/compiler design decision
> seems pretty lame to me. Another thing you cannot do is ask for the
> current thread to sleep when you are in the run method because the
> interface Runnable does not specify "throws InterruptedException"...
> I am sure there are lots of other such examples.
This is not true. You can call sleep() and wait() all you want, but if
the advertised API for the method that you are implementing does not
allow you to propagate an InterruptedException to the caller, then you
must catch that exception yourself and handle it gracefully.
A graceful way to handle the InterruptedException in a run() method is
to simply return from the method.
...jim
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
