Re: Uncatchable exceptions

On 2016-05-02 11:58 PM, Boris Zbarsky wrote:
> On 5/2/16 11:07 PM, Ehsan Akhgari wrote:
>> 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?
> 
> Hmm.  I don't think so, in general.
> 
> For example, say we have some C++ that does a JS_GetProperty on an
> object.  The property has a scripted getter, that scripted getter
> triggers the slow script dialog, the user opts to stop the script.
> JS_GetProperty will return false with no exception pending, indicating
> an uncatchable exception.
> 
> Or another example: running a toplevel script via JS_ExecuteScript never
> comes through js::InternalCallOrConstruct as far as I can tell.

Oh, right.  :(

>>> 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()?
> 
> No.  The whole point is that the uncatchable exception case is currently
> characterized by the following:
> 
> 1)  false was returned.
> 2)  JS_IsExceptionPending() is _false_.

Oh, I see.

So, for an embedder, is it possible to implement this by recording false
return values from JS APIs that can run code and then assume an
uncatchable exception if JS_IsExceptionPending() would be false?

>> The goal here is to expose whether execution was terminated because of
>> an exception that
>> is not catchable in JS.
> 
> Execution of which?  Are we just talking about execution of individual
> functions and toplevel scripts, or do we need to worry about the
> JS_GetProperty case above?

All of the above.