In Deferred I solved it by making end function with same signature as then:promise.end(function (value) {// do something with value
});If onerror callback is not provided, eventual error will just throw. So no extra (not needed) promise is created and any error either returned by promise or thrown in success handler will be exposed, that's what you should expect.
- .promise() becomes .promise
Anything else that you remember which will need to change? (I know this was a long time ago when you changed it so not a big deal if you don't remember)
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
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.
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.
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.
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.