> > I had high hopes for the domains api, but it looks like this idea is > either failed or has a very niche use, because I don't really remember any > projects that use it.
Domains are doing just fine. It's mostly an end-use API for use by application developers, but support for it is gradually showing up in the places where modules need a little extra shimming to work properly. The node-redis module now has support for domains, and hapi uses domains directly for its own error-handling. It's also pretty much a drop-in to write a middleware that works with Express or Restify to put all your middleware and route handlers into domains. 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. 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! F On Sun, Oct 27, 2013 at 7:30 AM, Peter Rust <[email protected]> wrote: > Benjamin, > > You may find TJ Holowaychuk's Koa.js > <https://github.com/koajs/koa>interesting -- middleware using generators. > Apparently there are big > performance benefits and you can catch both sync and async errors with > try/catch... but as others have said, it's experimental: you have to be on > the latest (unstable) release of node and you have to enable generators in > v8 with a command-line flag. > > You've probably read the official > warning<http://nodejs.org/api/domain.html#domain_warning_don_t_ignore_errors>about > using domains as a way to ignore errors, but I figured I'd post a > link just in case. > > Regarding domains, in The Future of Programming in > Node.js<https://groups.google.com/forum/#!searchin/nodejs/domains/nodejs/9afurRCTlOc/GvlFNmm_AtAJ>, > isaacs said: > > > Domains will be refactored to support more generic > > continuation-tracking systems, to enable alternative error-handling > > mechanisms in userland. Eventually the Domain module will be a thing > > that could be done in userland, but it will continue to be bundled > > with the Node binary. > > 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. > > -- > -- > 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 [email protected] > To unsubscribe from this group, send email to > [email protected] > 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 [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- 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 [email protected] To unsubscribe from this group, send email to [email protected] 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
