Re: Exception Names
On Sun, 29 Mar 2009, Lew wrote:
Karl Uppiano wrote:
Not so much a naming thing, but I kinda wish InterruptedException was a
runtime exception instead of a checked exception. IMHO, there may be
Then no one would handle it.
wait, they catch and "eat" the InterruptedException, often resuming in some
loop, when someone much higher up wanted to interrupt the wait and regain
control of the thread.
Making 'InterruptedException' runtime would not have helped; indeed, it
would have exacerbated the problem.
For once, i think i might agree with the anti-checked-exception crowd
here.
InterruptedException is almost universally misunderstood, and almost
universally dealt with by catch-and-forget. This is exactly the wrong
thing to do with it, but people do it because they're scared to let it
pass, or do what it takes to terminate their method early. The reason they
do it is that the compiler won't let them ignore it. It screams at them
until they throw or catch,
If it was a RuntimeException, the compiler wouldn't bother them, they'd
ignore it, and they'd effectively default to letting it pass, like
declaring it as a throws would do now. And that means that all their
methods would respond to interrupts by immediately stopping and
terminating, which is probably the right behaviour in most cases (and if
they're using finally blocks right, it might even happen cleanly). Code
which cared about interruption - the code which is expecting control to
return to it after interruption - could still catch it. Problem more or
less solved.
People would have learned the hard way that they were getting the
exception, then still handled it incorrectly.
Except most of the time, they wouldn't be getting it, i reckon.
Interruption isn't something that just happens, it happens when code
farther out has interrupted the code that's running, and in that case,
rapid transfer of control to that code is exactly the right thing to do.
tom
--
People don't want nice. People want London. -- Al