BluebirdJS promise with jQuery not working properly

Question

Using Promise.resolve($.ajax(options)) as mentioned here http://bluebirdjs.com/docs/api/promise.resolve.html is not working.

var $ = require('jquery');
var Promise = require('bluebird');

function makeRequest(options) {

      return Promise.resolve($.ajax(options))
        .then(function(data) { return data; },
              function (error) { return error; });

}

When I call and url that returns an error (403 in this situation), and I add one more '.then', it always calls the fulfilled handler.

makeRequest(options).then(iAmBeingCalledWhenTheRequestFails, iAmNotBeingCalled);

score 3 · Accepted Answer · answered Nov 13 '15 at 17:48

3

When you do:

  return Promise.resolve($.ajax(options))
    .then(function(data) { return data; },
          function (error) { return error; });

That's effectively doing:

try {
  return $.ajax(options);
} catch (e){
  return e;
}

Promises have exception handling like regular synchronous code, when you return form an exception handler you recover from the error (like try catch). If you want to add an error handler and keep the chain in a rejected state - you need to throw the error.

Better yet, don't attach the error handler in this case to begin with.

 return Promise.resolve($.ajax(options)); // that's all folks!

answered Nov 13 '15 at 17:48

Benjamin Gruenbaum

270,886
87
504
504

"when you return form an exception handler you recover from the error (like try catch)". Thanks very much, I think I was missing the point with promises (one of those things you think you know but you actually don't). – Walter Macambira Nov 13 '15 at 17:51
2

@WalterMacambira that's ok - jQuery very famously [missed the point of promises themselves](https://gist.github.com/domenic/3889970). – Benjamin Gruenbaum Nov 13 '15 at 17:53
isn't it bad for performance to `throw` just to repass the error? – Walter Macambira Nov 13 '15 at 17:57
1

@WalterMacambira exceptions should be extremely rare and for edge cases anyway (like the server returning an error) - so it should not be a concern anyway. You can also `return Promise.reject(err);` to do the same thing (since if you return a promise from a `then` handler the chain will assume its state) but honestly - it's not a big deal since exceptions should be extremely rare. – Benjamin Gruenbaum Nov 13 '15 at 18:00
2

@WalterMacambira If you don't actually intend to do anything with the error, then there's no reason to catch it in the first place. That's what the end of Benjamin's post says. – JLRishe Nov 13 '15 at 18:00
@JLRishe I need to handle the error in the case (tell the user why things wen't wrong). In this specific case, I am looking for any error message on $xhr.responseJSON, if none, it 'returns' the default error message. – Walter Macambira Nov 13 '15 at 18:08
1

@WalterMacambira on the client side unless you're doing tens of thousands of `throw`s the performance shouldn't be a problem. Even then - measure it. – Benjamin Gruenbaum Nov 13 '15 at 18:09
@BenjaminGruenbaum, you're right, there is no need to care about it in a scenario where it is a rare thing. But thanks for giving me an alternative. – Walter Macambira Nov 13 '15 at 18:10

BluebirdJS promise with jQuery not working properly

1 Answers1