From:  Jason Orendorff <jorendorff@mozilla.com>
Date:  12 May 2016 00:43:30 Hong Kong Time
Newsgroup:  news.mozilla.org/mozilla.dev.tech.js-engine.internals
Subject:  

Re: Generating an ErrorReport from a thrown value

NNTP-Posting-Host:  63.245.214.181

Yeah, you're right.

There's one usage pattern in particular where you grab the pending
exception state, set it aside, clear the context's pending exception, and
do some stuff; then possibly put the originally-pending exception back.
`finally` blocks are like this. Putting it back is the problem: you
probably want to retain the original stack that shows where the error
occurred.

For C++ code, see JS::AutoSaveExceptionState in jsapi.h - I think that's
the thing to use for this. It just needs another Rooted field to hold the
stack. Stuff like js::UnwindIteratorForException should be migrated to use
that class.

Most other setPendingException() callers should be able to live with the
engine just grabbing the current stack at that point...

-j


On Fri, May 6, 2016 at 4:17 PM, Jim Blandy  wrote:

> On Fri, May 6, 2016 at 8:51 AM, Jason Orendorff 
> wrote:
>
>> On Thu, May 5, 2016 at 12:39 PM, Jim Blandy  wrote:
>>
>> Of course we could store it off to the side, and thereby keep metadata
>>> about non-Error exceptions. That's just not what was implemented. It'd
>>> take
>>> some care to ensure that the metadata stayed attached to its exception
>>> value.
>>>
>>
>> I have kind of always thought we should do this; and never mind
>> "attaching" it to the exception value: it's just a separate piece of data
>> that's available in cx as long as an exception is pending. For users who
>> want it.
>>
>
> By "attached", I mean that we move exceptions in and out of the context
> for various reasons (I don't think `finally` clauses are the only case).
> All those will need to be kept in sync. This isn't any giant issue; there
> are only 25 uses of setPendingException. But it'll take a bit of care.
>
>