Re: Uncatchable exceptions

On 2016-05-02 9:47 PM, Boris Zbarsky wrote:
> On 5/2/16 9:13 PM, Ehsan Akhgari wrote:
>> I'm trying to figure out how to implement this function.  AFAICT the
>> implementation is roughly as follows:
>>
>> bool JS_IsUncatchableExceptionPending(JSContext* cx) {
>>    return cx->didSomeJSNativeReturnFalse() ||
>>           cx->isThrowingOutOfMemory();
>> }
>>
>> It is the didSomeJSNativeReturnFalse() that I don't know how to
>> implement.  As far as I can understand stuff that happens in js::Call()
>> et al, there isn't even a flag indicating such case. :(  It seems like
>> all that happens here is we return false and pass the ball to the
>> caller, which itself returns false and so on.
> 
> That's correct.  That is exactly how things work right now.

Sadface.  :(

> I think there are basically two options here:
> 
> 1)  We change the places that return false without setting pending
> exceptions to make some explicit call to an API we add.  The problem is
> finding them all.  :(  That said, it's not clear to me that SpiderMonkey
> itself ever has this behavior.  Gecko does, for the slow script dialog
> and worker termination, but all of that happens outside SpiderMonkey...
>  Presumably you need to implement a "throw uncatchable exception" API
> anyway, right?

Hmm, not sure why we would need to do all of this...  Now that I think
about it, I think we can have a flag that we set in
js::InternalCallOrConstruct() if that function returns false.  I _think_
that's the only place where these false return values can originate from?

> 2)  We restrict the use of JS_IsUncatchableExceptionPending to the
> situation when false is known to have been returned.  In that case it
> just becomes !cx->hasPendingException().

Wouldn't that essentially be JS_IsExceptionPending()?  The goal here is
to expose whether execution was terminated because of an exception that
is not catchable in JS.