-1

I m actually coding some functions using chained promises and I m having some trouble dealing with them.

Actually, here's the anti-pattern that I want to avoid :

  return promise.then((res)=>{
    return promise2.then((result)=>{
      return result;
    },(error)=>{
      return Promise.reject(error);
    });
  },(err)=>{
    return Promise.reject(err);
  });

I tried refactoring it the following :

  return promise.then((res)=>{
    return promise2;
  },(err)=>{
    return Promise.reject(err);
  }).then((result)=>{
    return result;
  },(error)=>{
    return Promise.reject(error);
  });

The fact is that I don't know at all of my rejected promises will act. It seems that my unit tests are all breaking after this refactor and I don't understand why. Maybe the behaviour...

In fact, does my (error) callback contain the (err) rejected value, or will it break completely and return the promise directly ?

Thanks for your help.

EDIT : okay I ll try with another example . Let's imagine that I need to make some arithmetic opeartions asynchronously by catching each possible error, at each possible level

  asyncAddition(5, -5).then((res)=>{
    return asyncDivide(100, res);
  },(err)=>{
    return Promise.reject('ERROR, you cant divide by 0');
  }).then((res)=>{
    return asyncMultiply(res, 10);
  }).then((res)=>{
    return res;
  },(err)=>{
    return Promise.reject('An error occured, number result is over 1000 ');
  });

Does the first promise rejected will break all the other in the chain ? Or will it continue ?

mfrachet
  • 8,772
  • 17
  • 55
  • 110

1 Answers1

2

An (error)=>{return Promise.reject(error);} error callback is about as useless as a (result)=>{return result;} success callback. Used with then, it's an identity. You can simply omit them:

return promise.then(res => promise2);

It seems that my unit tests are all breaking after this refactor and I don't understand why.

The two snippets you are posted will have equivalent results. Their exact flow might be a bit different, e.g. Promise.reject being called twice in the second example when promise is rejected, but if both promise and promise2 are standard promises with Promises/A+ semantics then this must not matter.

okay I ll try with another example . Let's imagine that I need to make some operations asynchronously by catching each possible error, at each possible level

Yes, it does make quite a difference here. Catching errors on multiple levels, and treating them distinctly, will have different outcomes. An error handler will handle all errors on a promise, that is, in the complete chain above it (but not in the scuccess callback of the same then call, see difference between .then(…).catch(…) and .then(…, …) for details).

I believe you are actually looking for

asyncAddition(5, -5).then(res => {
    return asyncDivide(100, res).catch(err =>{
        throw new Error('ERROR, you cant divide by 0');
    });
}).then(res => {
    return asyncMultiply(res, 10).catch(err => {
        throw new Error('An error occured, number result is over 1000');
    });
});
Community
  • 1
  • 1
Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • Why not use .Promise.all(arrofPromises).then(function() { console.log("all is ok"); }); – Tal Avissar Mar 18 '16 at 13:51
  • 1
    @TalAvissar: Because I have no idea what OP is actually doing. Yes, `Promise.all` might be a better solution to his actual problem, or it might not. I've just posted code that is equivalent to the one in the question, whether that makes sense or not. – Bergi Mar 18 '16 at 13:54