Exceptions thrown when linking sig-poly methods and indy

[David Holmes]

On 25/08/2016 8:20 AM, John Rose wrote:
> On Aug 24, 2016, at 3:02 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>>
>> 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.
>
> That's true for checked exceptions.  For unchecked errors, at least some
> of them,
> the implementation has always had the right to move them around.
> It would be reasonable, for example, for an implementation to vary in
> its choice
> to wrap, or not to wrap, a stack overflow error, or out of memory error,
> or thread-death, when passing through Method.invoke.  That's what
> we are talking about.
>
> That said, a very old API like jli.Method::invoke is going to have a lot
> of folks placing a lot of unstated expectations on it.  But a relatively

That's exactly my point - for compatibility reasons we can't make 
changes to existing behaviour in these core APIs.

> new one like invokedynamic, which does not yet have a wide range
> of use cases, can be changed without breaking many bits of code.

Presumably java.lang.invoke.* API's are in a similar position to 
java.lang.reflect etc - but I'm not very familiar with them.

David
-----

> — John