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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
