«

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 Canadian Mind Products
http://mindprod.com
Most of computer code is for telling the computer
what do if some very particular thing goes wrong.

On Fri, 29 Jul 2011 09:14:28 -0700, Roedy Green
<> wrote, quoted or indirectly quoted
someone who said :

>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.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Most of computer code is for telling the computer
what do if some very particular thing goes wrong.

On 7/29/2011 9:18 AM, Roedy Green wrote:
> On Fri, 29 Jul 2011 09:14:28 -0700, Roedy Green
> <> wrote, quoted or indirectly quoted
> someone who said :
>
>> 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.


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.

Roedy Green <> writes:

> 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)

--
Jukka Lahtinen

Jukka Lahtinen wrote:
> Roedy Green writes:
>> 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)

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...)'.

--
Lew

On Mon, 1 Aug 2011 23:54:34 -0700 (PDT), Lew <>
wrote, quoted or indirectly quoted someone who said :

>
>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.
--
Roedy Green Canadian Mind Products
http://mindprod.com
Most of computer code is for telling the computer
what do if some very particular thing goes wrong.

Roedy Green <> writes:

> On Mon, 1 Aug 2011 23:54:34 -0700 (PDT), Lew <>
> wrote, quoted or indirectly quoted someone who said :

>>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)

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.

--
Jukka Lahtinen

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?

On 08/02/2011 05:07 PM, Patricia Shanahan wrote:
>
> 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.