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
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
Most other setPendingException() callers should be able to live with the
engine just grabbing the current stack at that point...
On Fri, May 6, 2016 at 4:17 PM, Jim Blandy wrote:
> On Fri, May 6, 2016 at 8:51 AM, Jason Orendorff
>> 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
>>> some care to ensure that the metadata stayed attached to its exception
>> 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.