I totally understand what you're saying but I think there are a few things you're missing.
The problem we had with errors in the node implementation of promises, which was not great, was that errors were often unhandled because it was extra typing to write a handler for them. This lead to "silent" failures, which were terrible. This is why many better promise implementations throw entirely unhandled errors. Q (and i'll assume deferred and make broad generalizations about promises from here on out) has some amount of error propagation to make writing handlers for errors easier, and so that they can live in less places, and Q should not replace that with domains. BUT, if after propagation there is no handler it should emit error on the domain (if it exists). Now, in places where Q takes a success callback and then wraps that in a try/catch, it should also wrap code in the try statement in an enter/exit for the current domain. A throw will still be caught by your try/catch because domains don't do try/catch they wait for it to bubble up to uncaughtException, but making sure your user's code runs in the same domain they entered the promise with will mean that any event emitters or API calls (in libraries by authors that are domain aware) can also get attached. I *think* this is the right way to support domains in libraries like this. For good measure, I had a go at adding domains to async [ https://github.com/caolan/async/pull/185 ] to make sure that most of these ideas play out in real code. I'm also attempting to add them to node_redis but it's a little harder than I anticipated, the node_redis code is a bit obfuscated by insane amounts of optimization :) -Mikeal On Oct 4, 2012, at October 4, 20129:39 AM, Domenic Denicola <[email protected]> wrote: > > On Thursday, October 4, 2012 7:55:50 AM UTC+2, Mikeal Rogers wrote: > Domains work OOTB on all event emitters but have some complications with > callbacks and streams. > > Streams that are long running (like the redis client) don't get scoped to the > right domain since they are created early and never destroyed. > > Callbacks are not automatically bound to a domain, so any "normal" code in > them that throws will not be caught by the domain. > > At Summer Camp we discussed the best way to handle this problem. The solution > seemed to be that module authors, like the redis client, should not scope > their stream to a domain but instead must bind any callbacks passed to them > to process.domain if one exists. I would say the same should go for libraries > like async and any other library that "manages callbacks" > > This is a very long way of getting at what I think is the most important part > of flow control discussions after 0.8, that regardless of the abstractions > you use everyone needs to find a way to attach their errors to the "active" > domain if they want to be compatible with error handling in node.js. Just > like a promise library needs to expose something compatible with the callback > interface to get at APIs in core it'll need to check for process.domain and > bind it's success callbacks and error handling to it. > > I would love to play nicely with domains, but I'm not sure it's as > straightforward as this. Promise libraries wrap all callbacks in a try/catch, > storing any errors for potential future listeners, so there are no truly > unhandled exceptions---simply ones that nobody has listened for, yet. So I'm > not sure how you would surface those to a domain, or if it's even appropriate > to do so. Guidance definitely appreciated. > > There's also the larger point, promises entirely aside, of whether domains > are truly the future of error handling in Node. There has been no evangelism, > or tutorials, and from what I've seen, very little adoption. So far they > simply seem like the core team/illuminati's favorite error handling library, > which just so happens to be distributed with node instead of through npm. I'd > love it if everyone was agreed on a single solution, but the impression I got > from summer camp was that the only people using domains are those who are (a) > close to the core team, and (b) write applications, not just hack on node > core itself. > > As I said, I want domains to succeed, even if only from the > probably-in-your-eyes-misguided motivation that I like having standards > handed down to me that we can all agree on, whether it be ES6 or domains. But > I just don't see any effort or movement in that direction. > > -- > 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 -- 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
