ECMAScript error sink
From: es-discuss <es-discuss-bounces at mozilla.org> on behalf of David Bruant <bruant.d at 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 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.
On Wed, Nov 13, 2013 at 8:20 AM, David Bruant <bruant.d at gmail.com> wrote:
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?
On Wed, Nov 13, 2013 at 9:25 AM, Mark S. Miller <erights at google.com> wrote:
- 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".
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.
Le 13/11/2013 08:11, Boris Zbarsky a écrit :
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.