Mikeal, thanks, that's a very valuable guideline. I haven't yet look deeply into domains, now I definitely would.
On Thursday, October 4, 2012 7:55:50 AM UTC+2, Mikeal Rogers wrote: > > 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] <javascript:>> 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] <javascript:> > To unsubscribe from this group, send email to > [email protected] <javascript:> > 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
