I agree with the principal that you shouldn't shove all your control flow through event emitters, but I'd take it a step further, and say you should shove it all through *any* single abstraction.
We have event emitters, streams, callbacks and "normal" (sync) code at play in all node programs. each of those abstractions do one thing well, and don't do what the others do well. 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 know that part of the value proposition of these libraries has always been that they have their own error handling mechanisms but the reality is that once frameworks wrap their user's handles in a domain all the nice error handling logic of the framework will be attached to the domain and unless you want to make your users integrate all their promises in to the framework by hand you'll need to work with the active domain. The upside is that people using these frameworks will have an easier integration path with your promise library (as in, it'll just work). -Mikeal On Oct 3, 2012, at October 3, 20123:26 PM, Domenic Denicola <[email protected]> wrote: > On Tuesday, October 2, 2012 11:44:23 PM UTC-4, Raynos wrote: > domains have a parallel to sync code. Use event emitters for your sync flow. > promises only have a parallel to sync code if you use promises for sync & > async code. > > By "sync code" I meant code with functions that return values and throw > exceptions. (One might call this "normal code" :P.) Sure, you can do > everything with (sync) event emitters, but you lose guarantees like only one > return value, only one thrown exception, and never both from the same > function. You cannot make assumptions like that about your code's flow if > it's entirely structured through event emitters, which makes things harder on > the programmer---you can no longer focus on just getting things done but > instead have to worry about the technology you're using to do it. And of > course you have to rebuild all of the sync mechanisms like function > composition (obviously easy if your EEs are streams), exception bubbling > (harder, e.g. domains are top-down while exceptions bubble bottom-up), catch > clauses, finally clauses, etc. > > Not sure what you mean by the last sentence. What I meant by saying promises > parallel sync code is that there is an exact correlation between promise > concepts and sync code concepts, e.g. fulfillment value <-> return value, > rejection reason <-> thrown exception, rejection propagation <-> exception > bubbling, fulfillment value transformation <-> functional composition, > rejection transformation <-> catch clauses, and so on. You should never use > promises for sync code IMO. > > -- > 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
