Re: Checked Exceptions
On 12/17/2009 8:21 PM, Arne Vajh??j wrote:
On 17-12-2009 09:59, Eric Sosman wrote:
On 12/15/2009 6:10 AM, Andreas Leitgeb wrote:
Arne Vajh??j<arne@vajhoej.dk> wrote:
Then, give us some way to handle more than one type of exception in
the
same catch statement. "catch( FooException, BarException,
WeirdException ex ) { }"
That has been proposed before. I guess it is OK.
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.
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.
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.
--
Eric Sosman
esosman@ieee-dot-org.invalid