When should I reject a promise?

问题:

I'm writing some JS code that uses promises. For example, I open a form pop-up and I return a jQuery Deferred object. It works like this:

• If the user clicks OK on the form, and it validates, the Deferred resolves to an object representing the form data.

• If the user clicks Cancel, then the Deferred resolves to a null.

What I'm trying to decide is should the Deferred instead reject, instead of resolve? More generally, I'm wondering when should I resolve to something like a null object, and when should I reject?

Here's some code demonstrating the two positions:

// Resolve with null.
var promise = form.open()
    .done(function (result) {
        if (result) {
            // Do something with result.
        } else {
            // Log lack of result.
        }
    });

// Reject.
var promise = form.open()
    .done(function (result) {            
        // Do something with result.            
    })
    .fail(function () {
        // Log lack of result.
    });

回答1:

The semantics of your two strategies are not really the same. Explicitly rejecting a deferred is meaningful.

For instance, $.when() will keep accumulating results as long as the deferred objects it is passed succeed, but will bail out at the first one which fails.

It means that, if we rename your two promises promise1 and promise2 respectively:

$.when(promise1, promise2).then(function() {
    // Success...
}, function() {
    // Failure...
});

The code above will wait until the second form is closed, even if the first form is canceled, before invoking one of the callbacks passed to then(). The invoked callback (success or failure) will only depend on the result of the second form.

However, that code will not wait for the first form to be closed before invoking the failure callback if the second form is canceled.

回答2:

Since it's user-controlled, I wouldn't treat it as a "failure". The first option seems cleaner.

回答3:

Well, in both cases you would do something different, so i would say always either resolve it, or reject it. Do your form post on resolve, and on reject do nothing. Then, on always, close the form.

var promise = form.open()
.done(function (result) {            
    // Do something with result.            
})
.fail(function () {
    // Log lack of result.
})
.always(function() {
    // close the form.
})

If you aren't rejecting on cancel, when are you ever rejecting at all? at that point, why use a deferred object? You could reject on input error, but then you would have to generate a whole new promise if you wanted to allow them to fix it.

---

Deferreds don't really seem like the right thing to use here. I'd just use events.