>>>>However, when I was testing the above I saw that the status was undefined while error contained the information including status. What is the correct way for the catch block and do we need it at all?
>>>
>>>Without knowing what services.Http is it's not possible to answer that. If it's a simple wrapper around angular $http then only one parameter would be returned.
>>
>>Yes, it's a simple wrapper
>>

>>/**
>>         * @var $http Http
>>         * @type Object
>>         */
>>        Object.defineProperty(this,
>>            "Http",
>>            {
>>                enumerable: true,
>>                get: function() {
>>                    return $injector.get("$http");
>>                }
>>            });
>>

>>
>>My colleague adjusted all our services to the code I showed. Do you mean that code is incorrect and needs to be fixed to return error instead?
>
>No. Services.Http is thus just $http. Your code should not expect a second parameter in the catch()
>

This is exactly what I meant. Right now all our services are written this way

/**
     * @public
     * @param {string} id
     * @returns {ng.IPromise}
     */
    InvoicesService.prototype.getInvoice = function(id) {
        var deferred = services.Deferred;

        services.Http.get('api/invoices/' + id)
            .then(function(data) {
                deferred.resolve(data.data);
            })
            .catch(function(data, status) {
                deferred.reject(status);
            });

        return deferred.promise;
    };

So all of them have this catch block which is wrong. It should be

catch (function(error) {
   deferred.reject(error);
});

if we need the catch block at all in services. I don't think we need it. Originally we didn't have it.