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!

[benjamingr]

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;
    });
}

[petkaantonov]

If you don’t care about an operation like increasing the user counter failing, then handling the error is simply using an empty catch handler matching Promise.OperationalError. Then everyone reading the code understands that the intent is to ignore any possible error.

You don’t need to write it anywhere but in the incrementUserCounter() function:

function incrementUserCounter() {
     return query(...).catch(Promise.OperationalError, function(ignore){});
}