Catching mulitple Exceptions in JDK 1.7

[Roedy Green]

catch (IOException|SQLException ex) {
logger.log(ex);
throw ex;
}

Is it correct to say that I can't get at any of the parameters of the
IOException if I use the new JDK 1.7 multiple catch?

 

[Roedy Green]

catch (IOException|SQLException ex) {
logger.log(ex);
throw ex;
}

Is it correct to say that I can't get at any of the parameters of the
IOException if I use the new JDK 1.7 multiple catch?

Let's say you have an IOException. When you log ex, what are you
logging? There IS no SQLException to log.

It would have thought type of ex would have to be the deepest common
class of the two exceptions.

 

[markspace]

Let's say you have an IOException. When you log ex, what are you
logging? There IS no SQLException to log.

This is probably just a temporary error in thinking, but IOExcpetion
doesn't define any additional methods or properties beyond what
Exception defines (I'm ignoring "parameters"). So no worries there.

As for what you are logging, it's "ex."

It would have thought type of ex would have to be the deepest common
class of the two exceptions.

Probably Exception. At least must be Throwable. No I don't have a
revised JLS handy, I'll take a look.

 

[Jukka Lahtinen]

catch (IOException|SQLException ex) {
logger.log(ex);
throw ex;
}

Is it correct to say that I can't get at any of the parameters of the
IOException if I use the new JDK 1.7 multiple catch?

if (ex instanceof IOException) {
IOException ioe = (IOException) ex;
...
}

Of course, if you need something in the catch block that is specific to
IOException, you probably wouldn't do
catch (IOException|SQLException ex)

 

[Lew]

if (ex instanceof IOException) {
IOException ioe = (IOException) ex;
...
}

Of course, if you need something in the catch block that is specific to
IOException, you probably wouldn't do
catch (IOException|SQLException ex)

SQLException /is-an/ IOException, so there isn't anything "specific to IOException" that isn't in SQLException. It's the other way around. Roedy waspointing out that if you use multi-catch on IO/SQL, that you can't get at the stuff that's specific to SQLException. But as you correctly point out,if you need to handle the two cases differently, you wouldn't combine them..

In fact, if you only want to handle the IOException-ness of the exception, you wouldn't even bother mentioning 'SQLException' at all. You'd just 'catch(IOException...)'.

 

[Roedy Green]

In fact, if you only want to handle the IOException-ness of the exception, =
you wouldn't even bother mentioning 'SQLException' at all. You'd just 'cat=
ch(IOException...)'. =20

Here is a better example to illustrate my question:

catch (IllegalArgumentException|IOException ex)

What is the compile-time type of ex?

What is the run-time type of ex if you got an
IllegalArgumentException?

What is the run-time type of ex if you got an IOException ?

There may be more grown-up terms for "compile time type" and "run time
type", but I think you know what I mean.

Or is there a rule that catch (a | b ex ) requires a to be a subclass
of b, which would neatly sidestep the problem, but then the feature
would not do anything useful.

 

[Jukka Lahtinen]

Here is a better example to illustrate my question:
catch (IllegalArgumentException|IOException ex)

I think we understood your original question.

What is the compile-time type of ex? ...
What is the run-time type of ex if you got an IOException ? ...
Or is there a rule that catch (a | b ex ) requires a to be a subclass
of b, which would neatly sidestep the problem, but then the feature
would not do anything useful.

That restriction wouldn't make any sense. If a extends b, there's no
point in catch (a|b) since you could do exactly the same with just
catch (b).

I haven't studied how it is handled, but I *suppose* the compile-time
type is the most specific Throwable that both a and b are subtype of
(probably in most cases Exception or some subclass of it). But of course
it wouldn't catch other subtypes that aren't either a or b or some
subtype of one of them.

And at runtime the JVM should know the exact type and you should be able
to ask it with instanceof like anywhere else, like I suggested in my
earlier followup.

if (ex instanceof Foo) {
Foo bar = (Foo) ex;
...
}

But if you need to do that, you should't catch multiple types with
the same catch.

 

[supercalifragilisticexpialadiamaticonormalizeringe]

On 02/08/2011 5:07 PM, Patricia Shanahan wrote:
....

It seems to generally do the most useful thing it could, but I really
would like documentation that would let me predict the results without
running the experiments.

I wonder if Oracle isn't as committed to quality documentation (or,
perhaps, to Java at all) as Sun was.

I also wonder what happens with this:


public void method () throws SomeCheckedException,
SomeUnrelatedCheckedException {

try {
throwSomething();
} catch (SomeCheckedException | SomeUnrelatedCheckedException e) {
logger.log(e);
throw e;
}
}

Does this work? Or does method() need throws
LastCommonSupertypeOfThoseCheckedExceptions instead to avoid a compile
error?

 

[Jeff Higgins]

I've done an experiment, with interesting results.

Before I go into more detail, I must protest...

<http://jcp.org/aboutJava/communityprocess/maintenance/jsr901/index3.html>
See: Comments To

I had a quick look through the "normative version" and couldn't find
a specification for this behavior. There is a good chance I could have
overlooked it.