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 hotspot-dev
mailing list