Mochabot log - CommonJS IRC channel: #commonjs on irc.freenode.net

2010-08-16:

[15:02] <nrstott> Should the 'reject' parameter to a promise be used for a normal failure condition handler or is it intended more for situations when something goes awfully wrong and there is an unexpected failure?
[15:02] <nrstott> s/parameter/callback
[15:04] <deanlandolt> nrstott: IIUC the reject cb typically takes an Error obj as an arg
[15:04] <nrstott> deanlandolt, im more asking from an API standpoint... for instance if i have a saveDoc method in a couchdb client that is promise based, should the 'reject' callback handle 409s
[15:04] <deanlandolt> so if you're async db handling, for instance, runs into an issue midway through streaming a response, you would propogate that error by way of deferred.reject(e)
[15:05] <deanlandolt> oh, i see...sorry, i was inside out
[15:05] <nrstott> from a programmer point of view, having to handle 409s in the success callback and then crazy errors in the reject callback would make promises more inconveniant than the node style of function(err, resp)
[15:05] <deanlandolt> i'd say that depends on whether your http client throws an error on >=400 (stupid java!)
[15:05] <nrstott> well mine doesn't, promised-ios ^^
[15:06] <deanlandolt> but the answer is probably not...though you may want to propogate that as an error in the couch client itself
[15:06] <nrstott> however, in my API I am considering throwing on >= 400
[15:06] <deanlandolt> yeah, that's where it makes sense -- so you'd take your 409 in the success client and propogate an error via deferred.reject
[15:06] <nrstott> if the end-user of my API has to do when(db.saveDoc(...), function(resp) { if (resp.code === 409 .... ), function(err) { ... } )
[15:06] <nrstott> that'd be an awful exerience
[15:06] <deanlandolt> or, just throw actually
[15:07] <deanlandolt> yeah, that'd be almost as bad as the node convention of if (err) throw err :D
[15:08] <deanlandolt> so yeah, the consumer of your client would want to use the second callback to handle errors...they wouldn't see 409s
[15:08] <nrstott> makes sense
[15:08] <kriszyp> at the low level http handler, a response is a successfully fulfilled promise, regardless of status code, at a higher level that understand status codes and how to react to them, a error status code should trigger a rejected promise
[15:08] <deanlandolt> you would just throw (or, if you've got a handle on the deferred, do deferred.reject(SomeErrorObject)
[15:08] <deanlandolt> yeah, that :D
[15:08] <nrstott> here's a gist
[15:08] <nrstott> http://gist.github.com/527190
[15:09] <nrstott> is there anyway that i coul avoid throwing that error and invoke their reject callback in a different way?
[15:09] <nrstott> oops logic error in that gist in the first line ;0
[15:09] <nrstott> but ignore that
[15:09] <deanlandolt> yes, let me dig something up...
[15:10] <deanlandolt> nrstott: http://github.com/deanlandolt/perstore/blob/master/lib/store/couchdb.js
[15:10] <deanlandolt> still looking for a line number...i was sure i was doing raw deferred handling there but can't seem to find it
[15:14] <nrstott> is there a higher-level abstraction to chain promises?
[15:14] <nrstott> so i can say "when this promise is resolved, next do this" with an array of promise-returning actions?
[15:15] <deanlandolt> i seem to remember some helpers in promised-io
[15:15] <deanlandolt> in any event, here's another approach to propagating errors: http://github.com/kriszyp/promised-io/blob/master/engines/rhino/lib/fs.js#L12-18
[15:17] <nrstott> thanks dean
[15:17] <nrstott> 'all' is kind of what i want, but i want htem done in order
[15:18] <nrstott> ah 'seq' appeasr to be it
[15:18] <nrstott> cept i dont really care about the return value of the previous promise
[15:18] <nrstott> in fact, that kind of ruins it ;0
[15:18] <nrstott> i need to pass other values
[15:18] <nrstott> ill model a helper after that though
[15:18] <deanlandolt> cool
[15:19] <deanlandolt> if it's generalizable throw the new helper back into promised-io
[15:19] <nrstott> ill see if i can make it generalizable
[15:28] <dmachi> nrstott: to the extent that they are like deferreds (and i believe at least teh dojo implemenation does this with its version of promises (replacing the older dojo.deferred), if a callback function returns another another, the outer promise's chain will pause until the inner promise has called back and had its chain exhausted.
[15:28] <nrstott> dmachi, im trying to avoid deep nesting
[15:29] <dmachi> isn't that what "so i can say "when this promise is resolved, next do this" with an array of promise-returning actions?" describes?
[15:29] <nrstott> it describes deep-nesting, yes, but with a higher-level helper it could look cleaner in code
[15:30] <nrstott> im tired of writing return when(...., function() { return when(..., function() { return when}
[15:30] <nrstott> for actions that really have nothing to do with one another but just need to be executed in order
[15:30] <dmachi> i'd think you only need to do that when they have their own set of callbacks and you want to include them in the chain
[15:31] <dmachi> otherwise its just then?
[15:31] <nrstott> hm i guess i could just chain thens
[15:31] <dmachi> right
[15:31] <nrstott> Kris Kowal has brainwashed me into not using 'then' I guess :)
[15:32] <dmachi> :)
[15:33] <dmachi> you either chain the promises as above, or the callbacks themselves
[15:33] <nrstott> yeh i see what you're saing
[15:33] <dmachi> i think the difference, iirc, is that with the chained then's like this, they dont' get the value of the previous callbacks return like traditional deferreds
[15:34] <deanlandolt> nrstott: you don't have to nest your whens
[15:34] <nrstott> yeh i gather tha now
[15:34] <nrstott> i can just when a bunch off the same promise
[15:34] <deanlandolt> you can say var result = when(...); result = when(result...)
[15:35] <deanlandolt> yep

 

 

Logs by date :