Checked Exceptions

[Eric Sosman]

I don't quite get it, what would be the actual compiletime type of "ex"
in the (here empty) catch-block.

It might be Throwable, or Exception, or maybe the least
common superclass of FooException/BarException/WeirdException.

Such a dodge might create additional complications of its
own, since the only methods and fields you could use with "ex"
would be those of the chosen superclass. Most (all?) of Java's
own exceptions inherit everything from Throwable so an "ex" type
of Throwable would be all right, but if FooException has a
getOffendingFoo() method you couldn't use it until you'd done a
downcast -- which, in a "combined catch," would probably need
instanceof or other reflective techniques clumsier than the
separate catch blocks being replaced.

 

[Arne Vajhøj]

They do something different as checked and unchecked. If they are
different then different types is the most natural.

I don't agree that checked and unchecked exception actually _do_
anything different: whether an exception is checked or unchecked
doesn't matter when it is thrown, it doesn't matter when it is caught[1]
and it doesn't matter when the exception is processed. Even the
exception itself doesn't care.

In fact, the only time anything _does_ care if an exception is
checked or unchecked is at compile-time, which I think shows that
this isn't a case of behaviour or type but of semantics.

Generic types is a compile time thing, but very type related.

I still don't think this difference has anything to do tied with the OO
type system and having it tied to it only serves to add clutter with
otherwise pointless extra classes.

OO is very much about using type to carry information.

Fairly useless, yes, but it'd still give you some idea of in which ways
a method is likely to fail gracelessly. I'd have _liked_ to have _all_
unchecked exceptions declared (except the exceptions from the runtime),
but I realise that would get ridiculous for the top-level methods in
a large system. (Still, might have gotten people to put more thought
into their exceptions hierarchies.)

I would consider having maybe 25% of exceptions listed to be worse
than having 0% listed, because it may gives users a false impression.

Eh. I don't see why that should be the case. It's just one level of
indentation and the position of a single }. Not exactly ROT-13ing.

The whole point of having a { } for a method is to have then entire
method insider it.

How's it encapsulated? The way multiple catch statements are evaluated
is just syntactic sugar to avoid having to write a chain of "elsif( ex
instance of X)". There's no real abstraction added or any additional
access rules being enforced, so where's the encapsulation?

The encapsulation is exactly what you describe.

Arne

 

[Arne Vajhøj]

It might be Throwable, or Exception, or maybe the least
common superclass of FooException/BarException/WeirdException.

It may be the only possible solution.

Such a dodge might create additional complications of its
own, since the only methods and fields you could use with "ex"
would be those of the chosen superclass. Most (all?) of Java's
own exceptions inherit everything from Throwable so an "ex" type
of Throwable would be all right, but if FooException has a
getOffendingFoo() method you couldn't use it until you'd done a
downcast -- which, in a "combined catch," would probably need
instanceof or other reflective techniques clumsier than the
separate catch blocks being replaced.

But the construct would only be used if the exceptions were
indeed to be handled identical. Otherwise the old way could
and should be used.

Arne

 

[Eric Sosman]

It may be the only possible solution.


But the construct would only be used if the exceptions were
indeed to be handled identical. Otherwise the old way could
and should be used.

That's my opinion, too, but possibly not that of the
O.P. (No, wait: The O.P. was Arved Standstrom, and this
sub-thread was started by Leif Roar Moldskred. So for
"O.P." read "LRM." -- think of it as an override.)
Anyhow, LRM. showed an example that caught IOException
and handled various subclasses differently (three cases in
a switchy construct). The example also caught Exception
and sort-of-switched three ways on four subclasses.

My prejudice is that if you're going to give different
treatment to different exceptions, using different catch
clauses is a simple and natural approach. The only situation
in which I can imagine a catch-several-classes clause being
useful is if you wanted to catch some but not all subclasses
of some Exception type and treat them identically -- while
letting other subclasses of the same superclass escape the
catch altogether. IMHO that's too rare a circumstance to
justify a new language construct and new rules to support it,
but YMMV. Or LRMMMV, I guess.