ARM and repeating exceptions

[Joseph Darcy]

Hello Aleksey,

On 5/23/2012 9:01 AM, Aleksey Shipilev wrote:
> 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?

It is not prohibited, it just causes an exception ;-)  The behavior you 
have reported is required by the current specification.  However, I do 
not think elaborating on this point is worthwhile in the AutoCloseable 
javadoc since I think this situation will be a rare occurrence in 
practice and an explicit note about it would tend to nearly always 
distract rather than inform.

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

The semantics of the try-with-resources feature are tightly specified, 
as are the semantics of other language features.  Try with resources is 
specified in terms of a desugaring, as is the for-each loop from JDK 5.  
Early implementations of try-with-resources were available well ahead of 
JDK 7 shipping and developers were explicitly encouraged to try out 
try-with-resources and give feedback. [1]  Based on usage of the feature 
and feedback sent to coin-dev and elsewhere, the try-with-resources 
handling of null was adjusted before JDK 7 shipped. [2]

-Joe

[1] https://blogs.oracle.com/darcy/entry/project_coin_try_out_try
[2] https://blogs.oracle.com/darcy/entry/project_coin_null_try_with