bluebird: How to properly reject Promise and why deferring is anti-pattern?

Hi @petkaantonov , I would love if you have spare 10 minutes to read this question of mine: http://stackoverflow.com/q/28761365/2065080

I just don’t understand why deferring is an anti-pattern (as well as .then(success, fail)). I’ve posted an example (which I can also post here) with my real-life problem that I can’t seem to solve properly. I can’t get promisify to work and I ended up deferring.

You’ve stated those anti-patterns, but I can’t seem to understand why is that so.

Thanks in advance!

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 16 (7 by maintainers)

Most upvoted comments

Hi @fourpixels

Doing throw new Error is the correct approach (although please consider throwing custom errors and not just Error). Doing return Promise.reject(...) will also work

The fact it “blows up” if no handler is attached is great. It’s the same thing that happens in synchronous exceptions - if your application has an error and it was not handled you’d expect it to at least tell you.

If you want to suppress an exception it’s quite easy to do so:

myApiDbIncremenet().catch(function(){});

Which is similar to a synchronous:

try {
     doSomething();
} catch(e){
    // suppress exception
}

Also - for your findFirst example it could simply be:

function findFirst() {
    return Entity.find(1).then(function(result) {
           if(!result) throw new Error("No results found"); // consider a custom error
           else return result;
    });
}