Re: Where shoul I throw RuntimeException
"I V" <email@example.com> wrote in message
On Wed, 20 May 2009 08:00:30 -0700, Lew wrote:
I assess that people who dislike checked exceptions are those who write
client code that is forced to handle them. That is, of course, the
reason why checked exceptions exist - to force client code to deal with
them. Checked exceptions are an API writer's friend.
I'm kind of theoretically skeptical about Java's checked exceptions,
although the problem isn't the checking, but having to specify them,
which forces code that otherwise doesn't need to know about exceptions to
deal with them. The fact that exceptions propagate through layers until
they reach the appropriate level at which to handle them is one of their
advantages; forcing the author to specify exceptions at every level gets
in the way of that, cluttering the intermediate layers. The compiler
knows (or, could work out) what exceptions a method could throw, and it
could check they get handled without requiring they are specified
If you don't know how to deal with a checked exception, then you ignore it,
and declare that your method might "throw" it. Or you catch it, and re-throw
it as something that you want your API to throw. How else will you tell
*your* callers about it?
Having said that, I haven't actually found specifying exceptions to be as
much as a problem as I would have imagined. I'm coming round to the view
that the distinction between checked and unchecked exceptions reflects a
pretty real distinction between those exceptions that should be handled
close to where they occur, and those that don't.
Yes, the Java designers were very thoughtful in realizing that there are
situations where you want checked exceptions, and ones where you don't. My
quibble is in the choice of the Java API making some exceptions checked that
I think should be unchecked, and vice versa -- e.g., we had a discussion
here about InterruptedException a while back. Not everyone agreed with me.
Most peculiar, mama!