[2032] in java-interest
Re: throws declataration in Java/beta
daemon@ATHENA.MIT.EDU (Ken Arnold - Sun Labs)
Fri Sep 22 04:49:25 1995
Date: Thu, 21 Sep 1995 18:46:16 -0400
From: arnold@cocolat.East.Sun.COM (Ken Arnold - Sun Labs)
To: java-interest@java.Eng.Sun.COM
>But if I can't sleep in the Run method (as the mail below suggests),
>which is something you very commonly want to do, then I think
>something is horribly broken.
As the words on the front of the HHGTTG say:
DON'T PANIC
A method cannot throw an exception type not declared in its throws
clause. This is good. You now know which exceptions can be thrown by
a method.
Obviously this means that an overridden method cannot throw something
not in its the original method, since that would give you a method that
threw something not expected by the invoker who only knew the object as
its supertype. This is good. You still know which exceptions can be
thrown by a method, whether it gets overridden in an extended class or
not.
If a method invokes another method that throws an exception, there are
two cases:
(1) That method is compatible with the calling method's throws clause.
Everying is cool; the calling method can catch or not catch the
exception.
(2) That method is not compatible with the calling method's throws
clause. Everything isn't cool, because if that exception isn't
caught, the calling method could pass through an exception it isn't
supposed to throw. So the calling method must catch that
exception.
Now, let us look at Thread.run(), which throws nothing. Of *course*
you can invoke Thread.sleep(), even though Thread.sleep() throws
InterruptedException. The rule is that you have to *catch* it so it
doesn't leak through to the invoker of run().
Now, you can argue that run() should have a "throws
InterruptedException", but then you have to ask what it means to
"interrupt" run(). What interrupting sleep() means is well known.
Ken Arnold
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
