1

parse.com offers a cloud-code section so that I can write javascript code to modify my parse.com database.

I have such a cloud code function that does multiple things - say, checks if a user exists, and if the user exists saves some data in a different table and then updates the user table to reference this new table - so I would have one parse.Query that checks if the user exists, and then several then statements to run the update on the other table and get the user table to reference this new row.

In this scenario, am I meant to have several error functions (eg one for each parse.Query), or is it acceptable to have one error function in the very last then promise?

Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
bharal
  • 15,461
  • 36
  • 117
  • 195
  • see also [Do I always need catch() at the end even if I use a reject callback in all then calls?](http://stackoverflow.com/q/30881106/1048572) – Bergi Sep 19 '15 at 21:16

1 Answers1

6

Yes. It is acceptable.

Promises are like exceptions, having an error function for each .then is like having a .catch block for each statement:

try{
    first();
} catch(e) {
    //handle
}
try{
    second();
} catch(e) {
    //handle
}
try{
    third();
} catch(e) {
    //handle
}

Often, having one catch is more natural and clearer

try {
   first();
   second();
   third();
} catch (e) {
    // handle error in whole flow.
}

Likewise with promises:

 first().then(second).then(third).catch(function(e){ /* handle error */});

Or, with implementations without catch like Parse.Promise:

 first().then(second).then(third).then(null,function(e){ /* handle error */ });

The flow of control would be exactly like you would expect - if first fails, then it'll be handled by the first error handler, and it will not execute and fulfillment callbacks in the process so:

Parse.promise.as(true).then(function(){
    throw new Error("Promises are throw safe and throws are rejections! funstuff");
}).then(function(){
    alert("This will never show");
}).then(function(){
    alert("This will never show either");
}).then(null,function(e){
    alert("This is the error handler!" + e.message);
}).then(function(){
   alert("Since the error was handled this will show");
});

Always think about the synchronous analogue when considering how promises might behave.

Roamer-1888
  • 19,138
  • 5
  • 33
  • 44
Benjamin Gruenbaum
  • 270,886
  • 87
  • 504
  • 504
  • Apparently jQuery (and hence Parse) promise errors are not handled by an error function, unless it returns a promise. That is, the last alert will actually not fire! I have tested this with Parse Cloud Code. – Dmitri Zaitsev May 07 '14 at 04:51
  • @DmitriZaitsev if I may suggest, use a decent promise implementation. Adding Bluebird, all you have to do is `Promise.cast` (or event just `Promise.resolve` ) your promises which would cause them to be trusted Bluebird promises giving you a much much richer, faster and more debuggable API. – Benjamin Gruenbaum May 07 '14 at 06:26
  • Unfortunately I have limited control on that for Parse Cloud Code. However, with their curret promise API all I need to remember is to return a promise in each callback. – Dmitri Zaitsev May 07 '14 at 06:40
  • Here is Parse's explanation in details: http://blog.parse.com/2013/01/29/whats-so-great-about-javascript-promises/ – Dmitri Zaitsev May 07 '14 at 06:49
  • Concerning using Bluebird or other external libraries - I need to see a real payoff for jumping through the whoops. Something that can't be easily achieved with the out-of-the box Parse's implementation. – Dmitri Zaitsev May 08 '14 at 12:12
  • @JoeBlow I swear, promises are simple - in a month if you're using promises you'll be as good at this. At their core they're much simpler than callbacks :) – Benjamin Gruenbaum Sep 10 '15 at 09:00