Exceptions thrown when linking sig-poly methods and indy

David Holmes david.holmes at oracle.com
Wed Aug 24 22:02:01 UTC 2016


On 25/08/2016 4:37 AM, dean.long at oracle.com wrote:
> On 8/24/16 10:18 AM, John Rose wrote:
>
>> On Aug 24, 2016, at 10:04 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
>>> So we are talking about this kind of catch and re-throw pattern:
>>>
>>>   try {
>>>     x();
>>>   } catch (Throwable t) {
>>>       if (t instanceof Error) {
>>>           // Pass through any Error
>>>           throw (Error) t;
>>>       }
>>>       // Wrap any Throwable that is not a subclass of Error
>>>       throw new LinkageError(t.getMessage(), t);
>>>   }
>> Yes.
>>
>> System-level methods should have "throws Throwable", in which
>> case this equivalent formulation is slightly more future-proof IMO:
>>
>>   try {
>>     x();
>>   } catch (Throwable t) {
>>       if (!(t instanceof Exception)) {
>>           // Pass through any Error (or other non-Exception if such a
>> thing exists)
>>           throw t;
>>       }
>>       // Wrap any Throwable that is not a subclass of Error
>>       throw new LinkageError(t.getMessage(), t);
>>   }
>>
> Related to this, I always thought that java.lang.reflect.Method.invoke
> should do something similar when wrapping with
> InvocationTargetException.  Does anyone think the Method.invoke spec or
> behavior also needs clarification?

There is a long history of problems in this area - see Class.newInstance 
for example (which can throw undeclared checked exceptions!). 
Unfortunately for public API's the ship has sailed and we really can't 
do anything to change the existing behaviour.

David

> dl


More information about the jdk9-dev mailing list