Exceptions thrown when linking sig-poly methods and indy

[Remi Forax]

Hi all,
with my JSR 292 expert hat,
i agree that the JSR 292 spec should be amended to not wraps errors in BSME but as far as i remember, the JLS doesn't has a reference to java.lang.Exception, only Throwable, Error and RuntimeException are mentioned in the spec.
Throwable is the root of the checked exception, RuntimeException is the root of the unchecked one and Error is the root of the unchecked one that can be asynchronously thrown.

IMHO, the spec should say that errors (subtyped of java.lang.Error) are not wrapped into BSME
(like errors thrown in <clinit> are not wrapped in ExceptionInInitializerError (see JLS 14.18))

and if in the future we add a new subtype to Throwable with some special ability, we will fix the spec for that.

regards,
Rémi

----- Mail original -----
> De: "John Rose" <john.r.rose at oracle.com>
> À: "David Holmes" <david.holmes at oracle.com>
> Cc: "Uwe Schindler" <uschindler at apache.org>, "jdk9-dev" <jdk9-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoyé: Mercredi 24 Août 2016 02:39:14
> Objet: Re: Exceptions thrown when linking sig-poly methods and indy

> On Aug 22, 2016, at 5:19 PM, David Holmes <david.holmes at oracle.com> wrote:
>> 
>> "exception" (lower-case 'e') is a general term, all of the objects that can be
>> caught in a catch block are exceptions. If you want to refer to specific types
>> of exceptions then it needs to be clear e.g. Throwable, Exception, Error, etc -
>> actual type names with capitals.
> 
> Yes, that's how the spec. works.  I now think the spec. logic for wrapping BSME
> was
> written in error, partly because of the confusion between 'e' and 'E'
> exceptions.
> I.e., it's a design bug to fix in the spec.  We need a tracking bug for this.
> 
>>>> Or the spec is mostly right and (other than truly async exceptions like
>>>> ThreadDeath) any exception encountered due to the linking should be
>>>> wrapped.
>>> 
>>> Why only have special cases for such types? To me "Error" in general should
>>> never-ever be wrapped!
>> 
>> Async exceptions can be considered special cases as they are not caused by the
>> code being executed.
> 
> All unchecked exceptions (Errors) are special cases in that they are not cause
> by the specific
> API point that may throw them, but rather by some action of the JVM directly or
> indirectly
> triggered by the operation of an API.  That's why SOE and OOME are synchronous
> but
> unchecked:  They are not the product of any specific API point, even though they
> can
> leak through all API points.  Async errors are obviously and severely unspecific
> like this,
> but every non-Exception has a similar character.
> 
> Bottom line:  We need stop wrapping non-Exceptions in BSME, and instead allow
> all non-Exceptions to percolate out of JVM runtime actions that happen behind
> bytecodes.
> 
> Trying to distinguish "really unspecific" Errors from "specific though
> unchecked" Errors
> would be a losing game.  (I know the JVMS seems to play that game by giving
> special
> status to some in JVMS 6.3, but the fact that it leaves out ThreadDeath means
> that
> list is incomplete.  And there is no principle, in *any* spec., that would allow
> us to
> deduce that some subtype of java.lang.Error should be *excluded* from the 6.3
> list.)
> 
> — John