ARM and repeating exceptions

[Aleksey Shipilev]

Hi Joe,

On Wed, May 23, 2012 at 7:03 PM, Joe Darcy <joe.darcy at oracle.com> wrote:
> etc., define precisely what try-with-resources means.  This meaning does not
> support the usage pattern you have brought up.

I can see that. However, the rules for good language design dictates
the orthogonal features of the language should inter-operate. Are you
saying that current try-wth-resources spec prohibits throwing the
*same* (literally, the same) exception from close()? Would you care to
state that explicitly in AutoCloseable javadoc?

>
> The the Project Coin/JSR 334 effort took pains to include javadoc for
> Throwable.addSuppressed to discuss the difference between caused by and
> suppressed:

Yes, I had read that paragraph through even before the first reply.
Arguably, that paragraph tells you nothing about the behavior when the
secondary exception is equal()-ly the same. It does not really tell
you can get IllegalArgumentException out of thin air when using
try-with-resources. I would say that is the blind spot of the spec,
and I would strongly encourage us to do least astonishing thing in
that blind spot.

> The desugaring of try-with-resource in your code occurs "inside" the try
> block and does not include the catch IOException.  In other words, the
> implicit call to close is logically inside the try {...}catch.  Therefore,
> your code as written tries to have an exception suppress itself, which is
> rejected by the library code as documented.

The trouble is not about "rejected by the library code". The trouble
is surprising exception at the runtime. By the way, that surprising
IllegalArgumentException even masks the original one, thus
*completely* defeating the purpose of addSuppressed(). That becomes
refreshingly funny when the exception throwing code is the 3rd party
library code which users are "safely" using with try-with-resources.

This had already happened in real project. Fixing this glitch with
null-check will help this corner case without compromising the usual
behavior. As much as I love following specs to the ground, arguing
about safe change because you can't yet have simple correction to the
spec (why oh why the concrete desugaring code is the part of
not-really-changeable spec anyway?) feels too ivory-towerish for me.

-Aleksey.