> I'll mention Promises, which give you async versions of >> try/catch/finally[1] and… > > > Handling errors with promises is simple and clear (I find it one of the > most pleasant parts of working with promises), but until the advent of > bluebird, they incurred a pretty substantial performance penalty, if the > main reason you were using promises was for error-handling. Having all > those try clauses is expensive. And if you look at what bluebird has to do > to get around that, it's kind of hairy and not all that different from what > the domains system was doing under the hood. >
True. The end result however is an API that is simple and straightforward to use - arguably even easier than domains. > > Personally, I'm excited about this low-level hook because it should make >> it possible to implement automatic long-stack traces without hacks (though >> this is probably something you would want to have only in debug mode due to >> the performance implications). It might even make it possible to avoid >> littering the code with "if (err) return cb(err)" (or d.intercept) at ever >> layer of asynchrony -- that would be quite nice. > > > You should take a look at https://github.com/joyent/node/pull/6011, which > is the API to which Isaac is alluding. It's ready to be landed on node > master pending review, and has the error-handling hooks you describe (in > fact, in #6011, domains have been reimplemented in terms of the > asyncListener API). I've been working with this API for a month or two now > (I maintain the polyfill that brings its functionality back into 0.10 and > 0.8: https://github.com/othiym23/async-listener), and while I think it > offers a lot of improvements in terms of capturing information about > errors, it's not a full replacement for traditional Node error-handling. In > particular, you still need something like domains to keep the > error-handling happening as close to the scope of where the errors are > signaled as possible. > > And yes, the "Hello, World" of the asyncListener API is probably the long > stacktrace module. Trevor Norris (the implementor of #6011) wrote one to > debug the API, and a bunch of other people have done so as well. You're > right -- generating all those stacktraces is expensive! > > Interestingly enough, some preliminary tests of Bluebird<https://gist.github.com/spion/6990910>show that it may be viable to use its flavor of long stack traces in production<https://github.com/petkaantonov/bluebird#can-i-use-long-stack-traces-in-production> . -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
