On Fri, Feb 21, 2014 at 07:37:34PM -0800, Jan Krems wrote:
> For me one of the most powerful things about promises is that they can be
> passed around, returned from functions, etc.. It seems like your way of
> handlings errors prevents this. Or at least makes it very dangerous
>
> Take the following code:
>
> function* appendComment(id) {
> var user = dbHandle.load('user', { id: 'jen' });
> var thread = dbHandle.load('thread', { id: 1 });
> var comments = yield thread.getComments();
> // More code - but by yielding just before suddenly we might get an
> // uncatched error from the user promise in the first line.
> }
>
> We might have error handling further down - but it won't do us any good.
> It seems like your approach removes some of the nice guarantees that
> promises
> make compared to things like EventEmitters and callbacks.
Interesting mixing in generators like that -- it's the only way to do something
asynchronous before returning -- and it's really mixing two very alien
primitives there.
Why not
function appendComment(id) {
var user = db.load('user'),
thread = db.load('thread'),
comments = thread.thenPromise(function(R, th) {
R(th.getComments()); });
return [user, thread, comments];
}
instead, returning the promises -- no generator. If you're deferring error
handling to the caller, do it completely rather than mixing modes?
But it is a good point: promises that force you to handle errors don't play
that nicely when you enter the event loop before setting up the error handling.
What would your use case there be? What would error handling look like if you
used non-enforcing promises?
Aria
pgp3CrzmNIlTa.pgp
Description: PGP signature
