github at esdiscuss.org (2013-07-12T02:27:38.076Z)
Yes, that's the problem. My library is keeping a stack of suspended generators that corresponds to the stack of "await" calls. When an exception occurs I rethrow it into the suspended generators until it gets caught (see the run function in https://github.com/bjouhier/galaxy/blob/master/lib/galaxy.js). This works fine and the exception propagates through the stack of "await" calls exactly as you would expect it to (I have a series of unit tests that check all sorts of try/catch/finally combinations and they work). So the _propagation_ of exceptions through a stack of await calls works fine. What I am lacking is a way to reconstruct the stack trace of await calls when an exception is caught. As the exception goes through my little run function when it bubbles up I could easily collect the stack frames of the suspended generators into the exception object. The only thing that's missing is an API to get stack frame information from a suspended generator. My objective is not too much to get this await stack trace in the debugger, it is to be able to log it when the application is run without a debugger. A generator object represents a computation which has been suspended. We have an API to resume this computation (next/throw). What's missing is an API to get information about this suspended computation (which function, where in the source).
Yes, that's the problem. My library is keeping a stack of suspended generators that corresponds to the stack of "await" calls. When an exception occurs I rethrow it into the suspended generators until it gets caught (see the run function in https://github.com/bjouhier/galaxy/blob/master/lib/galaxy.js). This works fine and the exception propagates through the stack of "await" calls exactly as you would expect it to (I have a series of unit tests that check all sorts of try/catch/finally combinations and they work). So the _propagation_ of exceptions through a stack of await calls works fine. What I am lacking is a way to reconstruct the stack trace of await calls when an exception is caught. As the exception goes through my little run function when it bubbles up I could easily collect the stack frames of the suspended generators into the exception object. The only thing that's missing is an API to get stack frame information from a suspended generator. My objective is not too much to get this await stack trace in the debugger, it is to be able to log it when the application is run without a debugger. A generator object represents a computation which has been suspended. We have an API to resume this computation (next/throw). What's missing is an API to get information about this suspended computation (which function, where in the source). 2013/6/15 Kevin Gadd <kevin.gadd at gmail.com> > If I understand this right, essentially the problem is that an exception > could occur when some of the involved code is not alive on the stack > (because the generator(s) are suspended), and without the ability to > capture this information, the end user has no actual knowledge of why the > exception occurred. Yeah? > > That makes it hard to leave up to debuggers, since the debugger isn't > aware of your generator library and it's pretty hard to extend debuggers. > This is a common problem with custom task schedulers based on generators - > we had the same problem with imvu.task (debugging tasks in python) and I > had the same problem personally with my task scheduler in C#. The simplest > solutions (like aggressively capturing stack traces at some appropriate > point), even when they work, are pretty expensive. > > Is it possible to 'throw into' an ES6 generator? I can't remember if that > made it in - in Python, at least, that allows you to basically terminate a > generator wherever it is, and through doing so potentially capture a stack > trace for the generator after it terminates, from the error bubbling up > through the generator... that is, if I remember the semantics for when > python sets/overwrites tracebacks correctly. Using such a mechanism, you > could reconstruct an 'accurate' stack trace for any number of suspended > generators. > > -kg > > > On Fri, Jun 14, 2013 at 3:32 PM, Bruno Jouhier <bjouhier at gmail.com> wrote: > >> Thanks David. The problem is that I need it first in node.js, and if >> possible with a standardized API that works in all ES6 JS engines. >> >> I see this as being similar to asking for a portable "stack" property in >> Error objects. I don't know if it is actually mandated by ES6 but it looks >> like all major JS engines support it now. >> >> Note that caller and callee would not work for my use case. I need the >> frame info for a generator object which has been suspended, not from the >> generator function itself. >> >> >> 2013/6/14 David Bruant <bruant.d at gmail.com> >> >>> Le 14/06/2013 16:56, Bruno Jouhier a écrit : >>> >>> I'm using ES6 generators to implement a little async/await library and >>>> I'm quite pleased with the result so far but I'm lacking one API: a >>>> function to get stack information from a generator object. Ideally it would >>>> return the name of the current generator function, the filename and the >>>> line number where it last yielded. >>>> >>>> If I had this API I 'd be able to provide a complete trace of the stack >>>> of await calls when an exception is caught. >>>> >>> ES5 strict mode poisoned .caller and .callee. The reason is that it >>> isn't necessarily a good idea (security, maybe performance reasons as well) >>> to give authority to the runtime to inspect stack frames. It's more of a >>> debugger use case. >>> >>> The Debugger API in Firefox (only available to "Chrome-level" privileged >>> code) has a way to know the function being called, and to navigate across >>> the different frames like the caller frame ("older" property) [1] and some >>> infos that help finding the function name, filename and line number. >>> >>> David >>> >>> [1] https://developer.mozilla.org/**en-US/docs/SpiderMonkey/JS_** >>> Debugger_API_Reference/**Debugger.Frame<https://developer.mozilla.org/en-US/docs/SpiderMonkey/JS_Debugger_API_Reference/Debugger.Frame> >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130615/ec0cda10/attachment.html>