Re: Exception Names
"Lew" <noone@lewscanon.com> wrote in message
news:gqom2c$1cp$1@news.albasani.net...
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.
more incorrect code written to handle InterruptedException than all of
the others combined. More often than not, it seems when someone wants to
This is only the tip of the iceberg when it comes to incorrect thread
programming.
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.
These folks have obviously not read and assimilated /Java Concurrency in
Practice/ by Brian Goetz, et al.
Making 'InterruptedException' runtime would not have helped; indeed, it
would have exacerbated the problem. People would have learned the hard
way that they were getting the exception, then still handled it
incorrectly.
Face it, Java is a language that must be studied, and it must be learned.
Some of the problems it solves, such as multi-threaded programming, are
inherently hard. The language cannot make the problem easier; the best it
can do is not make it any harder.
The point of making an exception checked or not is not to prevent abuse of
the exception. Nothing but care by the practitioner can do that. The
point of making an exception checked is to identify methods that
intentionally throw that exception, and force their clients to deal with
it with a compile-time check. Forcing clients to deal with the exception
correctly is something that Java as a language cannot do.
Give us smarter programmers, not a smarter programming language.
I get all that. I know why we have runtime exceptions and I know why we have
checked exceptions. Sometimes exceptions fall into a gray area as to whether
it should be checked or unchecked, and I think InterruptedException falls
into that category, and I would have preferred that it was tossed into the
unchecked bucket. I have my reasons. I don't expect to convince you
differently. I???m just talking here.
But given the number of designs in which threads are interrupted (quite rare
in my experience -- I have seen it legitimately and brilliantly done exactly
once in 15 years of programming in Java), there seems to be quite a lot of
bad code written to handle that very rare exception. If someone calls
Thread.interrupt, they know what is going to happen, and they will design
their thread to deal properly with InterruptedException, whether it is
checked or not.
On the other hand, if I designed the thread, and I just want to wait -- I
know whether I???m calling Thread.interrupt, and it would be extremely
unexpected for someone else to call it unless I made the thread object
available to them. If such a runtime InterruptedException popped up after
all that, then I would say that a serious design review is in order.