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 (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
