Re: Uncatchable exceptions

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.

>> 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_.

> 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?

-Boris