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 <[email protected]> wrote: > On Fri, May 6, 2016 at 8:51 AM, Jason Orendorff <[email protected]> > wrote: > >> On Thu, May 5, 2016 at 12:39 PM, Jim Blandy <[email protected]> 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. > > _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
