Exceptions thrown when linking sig-poly methods and indy

[John Rose]

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