ECMAScript error sink (was: Weak callbacks?)

2013-11-13 Thread David Bruant
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

Re: ECMAScript error sink (was: Weak callbacks?)

2013-11-13 Thread Boris Zbarsky
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

Re: ECMAScript error sink

2013-11-13 Thread David Bruant
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

RE: ECMAScript error sink

2013-11-13 Thread Domenic Denicola
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

Re: ECMAScript error sink (was: Weak callbacks?)

2013-11-13 Thread Allen Wirfs-Brock
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

Re: ECMAScript error sink

2013-11-13 Thread Mark S. Miller
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

Re: ECMAScript error sink

2013-11-13 Thread Mark S. Miller
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

ECMAScript Error Sink

2013-11-13 Thread Kevin Smith
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 }

Re: ECMAScript Error Sink

2013-11-13 Thread Kevin Smith
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