Chained exception handling: bug?

[Robert Field]

Fixing this will require the back-end to send a result type that a prior 
version front-end would flag as a bad result code.  In that this will 
not break ExecutionControl instances written to the old SPI, I believe 
this is fine.  Yes?

-Robert



On 02/27/18 17:01, Robert Field wrote:
> Brian, yeah, yeah, that was it, a keep it simple choice.
>
> Rémi, as you both hit this -- the same day! -- I think it merits 
> addressing, soon.
>
> I've created:
>
>      https://bugs.openjdk.java.net/browse/JDK-8198801
>
> And I'm looking at it now.  Bit of a pain since it propagates from the 
> back-end, so requires an SPI change.
>
> -Robert
>
>
>
>
> On 02/27/18 16:00, Remi Forax wrote:
>> Funny, i've hit this exact same issue earlier in the morning.
>>
>> Rémi
>>
>> ----- Mail original -----
>>> De: "Brian Goetz" <brian.goetz at oracle.com>
>>> À: "kulla-dev" <kulla-dev at openjdk.java.net>
>>> Envoyé: Mercredi 28 Février 2018 00:45:50
>>> Objet: Chained exception handling: bug?
>>> If I evaluate an expression which results in throwing an exception, and
>>> that exception has a cause, the cause is not included in the stack 
>>> trace:
>>>
>>> jshell> $8.resolveConstantRef(MethodHandles.lookup())
>>> |  java.lang.BootstrapMethodError thrown: bootstrap method
>>> initialization exception
>>> |        at BootstrapMethodInvoker.invoke 
>>> (BootstrapMethodInvoker.java:174)
>>> |        at ConstantBootstraps.makeConstant 
>>> (ConstantBootstraps.java:66)
>>> |        at DynamicConstantRef.resolveConstantRef
>>> (DynamicConstantRef.java:308)
>>> |        at (#22:1)
>>>
>>> This exception had a chained cause, but it wasn't displayed. Was the
>>> choice to only process the first exception in the chain deliberate, or
>>> is this an omission?  (Its pretty hard to debug the above without the
>>> underlying cause.)
>