>>>>>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.

Doesn't matter that the parameter is there - but it will always be 'undefined' .......