just-boris
just-boris

Reputation: 9746

Angularjs promise rejection chaining

I need to create chained promises:

var deferred = $q.defer();
$timeout(function() {
    deferred.reject({result: 'errror'});
}, 3000);
deferred.promise.then(angular.noop, function errorHandler(result) {
    //some actions
    return result;
}).then(function successCallback(result) {
    console.log('what do I do here?');
    return result;
}, function errorCallback(result) {
   $scope.result= result;
   return result;
});

If I put an errorCallback into the first then, the second then will be resolved and its successCallback will be called . But if I remove errorHandler then second promise will be rejected.

According to Angular JS docs the only way to propagate rejection is to return $q.reject(); and it looks not obvious, especially because I have to inject $q service even if it is not needed;

It can also be done by throwing an exception in errorHandler, but it writes exception trace to console, it is not good.

Is there another option to do this in a clear way? And what is the reason? Why it is done? In which case, the current behavior can be useful?

Upvotes: 30

Views: 39503

Answers (2)

ant
ant

Reputation: 696

And what the reason why it is done. In which case, the current behavior can be useful?

It can be useful when in errorHandler you could try to repair error state and resolve promise somehow.

var retriesCount = 0;

function doWork()
{
    return $http.post('url')
        .then(function(response){
            // check success-property of returned data
            if(response.data.success)
                // just unwrap data from response, may be do some other manipulations
                return response.data;
            else
                // reject with error
                return $q.reject('some error occured');
        })
        .catch(function(reason){
            if(retriesCount++ < 3)
                // some error, let me try to recover myself once again
                return doWork();
            else
                // mission failed... finally reject
                return $q.reject(reason);
        });
}


doWork().then(console.log, console.error);

Upvotes: 68

Matthew.Lothian
Matthew.Lothian

Reputation: 2072

Late to the party, but as I am here;

I prefer to use the $http error for its native error handling, rather than returning a success via a 200 and an error status in the response.

printing 400 or 500 errors in the console is not an issue, if you are debugging you see them if not you don't.

angular.module('workModule', [])

// work provider handles all api calls to get work
.service('workProvider', ['$http', '$q', function($http, $q) {

    var endpoint = '/api/v1/work/';

    this.Get = function(){
        // return the promise, and use 404, 500, etc for errors on the server
        return $http.get(endpoint);
    };

}])

.controller('workController', ['workProvider', function('workProvider'){

    workProvider.Get().then(
        function(response){ // success
            console.log(response.data);
        },
        function(response){ // error
             console.log(response.data);           
        }
    )

}])

Upvotes: 5

Related Questions