CODEWITHSUNDEEP
javascriptangularjspromiseangular-promise
Kevin Meredith
Kevin Meredith

Reputation: 41909

Chaining Promises with Failure

Looking at this blog's post handling of promises, I modified the failure example:

var myApp = angular.module('myApp',[]);

myApp.controller("MyCtrl", function ($q, $scope) {

    (function() {
        var deferred = $q.defer();
        var promise = deferred.promise;
        promise.then(function(result) {
            console.log("success pass 1 - " + result);
            return result;
        }, function(reason) {
            console.log("failure pass 1, reason:", reason);
            throw new Error("failed with: " + reason);
        }).
        then(function(result) {
            console.log("2nd success! result: ", result);
        }, function(reason) {
            console.log("2nd failure! reason: ", reason);
        });


        console.log("calling deferred.reject('bad luck')");
        deferred.reject("bad luck");

    })();

For my first failure function, I noticed that replacing throw with return would result in:

calling deferred.reject('bad luck') 
failure pass 1, reason: bad luck 
2nd success! result:  Error {stack: (...), message: "failed with: bad luck"}

As a result, I replaced return with throw to achieve the desired failure -> failure result.

calling deferred.reject('bad luck') 
failure pass 1, reason: bad luck 
Error: failed with: bad luck at ...app.js
2nd failure! reason: Error {stack: ... "failed with: bad luck"}

The thrown error appears to not have been caught. Why is that? Shouldn't the inner failure case have caught this thrown error?

Also, in a chained promise, can a successive error case (in this case the 2nd chain promise's failure case) only be reached through the throwing of an Error?

Upvotes: 1

Views: 830

Answers (2)

user1375096
user1375096

Reputation:

you may have found by now. If you want to chain promises with failure, only supply failure handler at end of the chain.

    promise.then(function(result) {
        console.log("success pass 1 - " + result);
        return result;
    } /* don't handle failure here. Otherwise, a
         new promise (created by 'then') wraps the
         return value (normally undefined) in a new
         promise, and it immediately solves it 
         (means success) since the return value of
         your failure handler is not a promise.

         leave failure handler empty, 'then' will pass
         the original promise to next stage if the
         original promise fails. */
    ).
    then(function(result) {
        console.log("2nd success! result: ", result);
    }, function(reason) {

        /* both 1st and 2nd failure can be captured here */

        console.log("1st or 2nd failure! reason: ", reason);
    });

Upvotes: 0

Benjamin Gruenbaum
Benjamin Gruenbaum

Reputation: 276306

This is a design choice of $q which is very unorthodox in a sense.

A design decision was made in $q that throws and rejects are treated differently since the library does not track unhandled rejections for you. This is to avoid the case where errors get swallowed:

JSNO.parse("{}"); // note the typo in JSON, in $q, since this is an error
                  // it always gets logged, even if you forgot a `.catch`.
                  // in Q this will get silently ignored unless you put a .done
                  // or a `catch` , bluebird will correctly track unhandled
                  // rejections for you so it's the best in both.

They get caught, handled but still logged.

In $q, rejections are used instead:

return $q.reject(new Error("failed with: " + reason));

Upvotes: 1

Related Questions