ECMAScript error sink (was: Weak callbacks?)
Le 13/11/2013 06:15, Boris Zbarsky a écrit : On 11/12/13 11:07 PM, David Bruant wrote: I understand the need to know when a promise has an unhandled error at development time, I'm less clear on why you need to know it at runtime. Why would you do with this information? handle the error? The same thing that sites (e.g. Facebook) do with window.onerror: phone home to the server about the bug so it can actually get fixed. I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. Wrapping every single promise in case one ended up failing in an unexpected way feels way too expensive. There should be a sort of error sink feature instead. The browser has window.onerror for historical reasons, Node.js introduced Domains and Domain#intercept [1] for that reason IIUC. Isn't it the sign that ECMAScript should have this feature built-in? A global sink has something absurd to it, what about adding an error sink feature to module loaders? cc'ing ES6 Module folks Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. David [1] http://nodejs.org/api/domain.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink (was: Weak callbacks?)
On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. -Boris ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink
Le 13/11/2013 08:11, Boris Zbarsky a écrit : On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. That would be my definition. no one ever sets any reject callback on is itself undecidable (the ever part), but I feel it works well enough in practice. Cases where it doesn't, people have memory leaks. Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: ECMAScript error sink
From: es-discuss es-discuss-boun...@mozilla.org on behalf of David Bruant bruan...@gmail.com Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. `Domain.prototype.intercept` is a rarely-used feature of domains. Wrapping your callbacks in `domain.intercept` before passing them to a callback-accepting function is akin to attaching an error handler to a promise that always puts the error inside an error-storage box (domain) which you or someone else can centrally handle later. I do not think it's particularly relevant to error-handling discussions. The value of domains comes in them being a global switch you can turn on that allows all errors thrown within a given request/response cycle to be caught in a single place. (With certain problematic edge-case exceptions to this rule.) This allows you to associate uncaught errors with the request/response cycle in question, as opposed to the browser's `window.onerror` where you get no real context as to what caused the exception. This is especially important in Node where the same function (e.g. a HTTP server's request handler) can be called thousands of times at once, with different data, so the stack trace alone is not useful. More detail in [a presentation I gave](http://www.slideshare.net/domenicdenicola/domains-20010482) a while back. Domains are considered something of a band-aid and are being subsumed into a more general async listener API in Node.js 0.12. The async listener API gives you the ability to add AOP-style before/after handlers for any async operation in Node.js. (I believe libraries like Google's Closure accomplish this in the browser already, by wrapping all async APIs.) Domains will be re-implemented on top of async listeners for backward compatibility, but async listener is the new primitive for async interception of the type that domains were a special case of. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink (was: Weak callbacks?)
On Nov 13, 2013, at 7:58 AM, David Bruant wrote: ... The browser has window.onerror for historical reasons, Node.js introduced Domains and Domain#intercept [1] for that reason IIUC. Isn't it the sign that ECMAScript should have this feature built-in? A global sink has something absurd to it, what about adding an error sink feature to module loaders? cc'ing ES6 Module folks Uncaught exception handling doesn't seem like something that is naturally associated with a module loader or a Realm as a call stacks can wind through function objects that originated from many different Realms. It actually seems like something that would more naturally be associated with a turn. Perhaps anything that explicitly schedules a microtask should have the ability to associate an unhandled exception handler with it. Or, alternatively consider that every turn must begin by calling a function, so perhaps such a handler could just be represented as a function property. Engine uncaught handling would get the 'uncaughtException' property of the base function of the current stack. The implementation of 'uncaughtException' in Function.prototype would be a primitive that aborts the turn. Any function that might be used as a base functioin could over-ride 'uncaughtException' to do its own handling and perhaps finishing by doing a super call to the default. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. At least at the implementation level, unhandled promise error seem very different from unhandled exceptions. In fact, such an promise error may well represent a handled exception. I wonder, if a time-out model might not be a better one for dealing with the promises case. Allen [1] http://nodejs.org/api/domain.html ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink
On Wed, Nov 13, 2013 at 8:20 AM, David Bruant bruan...@gmail.com wrote: Le 13/11/2013 08:11, Boris Zbarsky a écrit : On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. That would be my definition. no one ever sets any reject callback on is itself undecidable (the ever part), but I feel it works well enough in practice. Hi David, I don't understand what you mean by it above. Because the question is undecidable, we need approximations. The two approximations that seem good are those that never have false negatives with few false positives, and those that never have false positives with few false negatives. They would bound the undecidable question from above and below. AFAICT, these are the two we've already discussed: * The console approach Domenic has previously described captures the approximation no one has yet set any reject callback on. * The finalization-based approach Kris explained captures the approximation no one can even set any reject callback on because the promise is unreachable. * And finally, the .done() operation provides even better accuracy at the price of asking programmers to more explicitly state their intent. Do you have in mind some way to better approximate the undecidable question than these? Do you have some way to do as well as, or better than, the second bullet without observing GC decisions? Cases where it doesn't, people have memory leaks. Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript error sink
On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller erig...@google.com wrote: On Wed, Nov 13, 2013 at 8:20 AM, David Bruant bruan...@gmail.com wrote: Le 13/11/2013 08:11, Boris Zbarsky a écrit : On 11/13/13 10:58 AM, David Bruant wrote: I'm sympathetic with this use case, but Weakrefs seem like the wrong tool to solve this problem. I think I agree on that. Ideally, the ECMAScript error sink would handled both uncaught thrown errors and unhandled promise errors. Defining unhandled promise error is not trivial, actually, unless you just mean rejected promise that no one ever sets any reject callbacks on. That would be my definition. no one ever sets any reject callback on is itself undecidable (the ever part), but I feel it works well enough in practice. Hi David, I don't understand what you mean by it above. Because the question is undecidable, we need approximations. The two approximations that seem good are those that never have false negatives with few false positives, and those that never have false positives with few false negatives. They would bound the undecidable question from above and below. AFAICT, these are the two we've already discussed: * The console approach Domenic has previously described captures the approximation no one has yet set any reject callback on. * The finalization-based approach Kris explained captures the approximation no one can even set any reject callback on because the promise is unreachable. can even set should be can ever set. * And finally, the .done() operation provides even better accuracy at the price of asking programmers to more explicitly state their intent. Do you have in mind some way to better approximate the undecidable question than these? Do you have some way to do as well as, or better than, the second bullet without observing GC decisions? Cases where it doesn't, people have memory leaks. Domain#intercept which looks at the Node error convention (error in async callback first argument) certainly suffer from the same issue, but looks practical enough. I lack the experience with Node domains. If some have it, it'd be interesting to share it. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
ECMAScript Error Sink
Hi Mark,
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Over in Dart they have implemented zones.
http://api.dartlang.org/dart_async.html
{ zen }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: ECMAScript Error Sink
The only approximation that seems acceptable to me is one that (a) never
has false negatives, and (b) provides a simple way for developers to
receive notification on and fix false positives.
Basic sysadmin stuff.
To finish the thought, `done` and `WeakRefs` fail (a), and console-only
solutions fail (b) in production environments.
{ zen }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
