Handling Errors From Services in Controllers - angularjs

Question

In my AngularJS application I am removing all $http.get() calls from my controllers and putting them into a custom service called $myService which will make the http requests and return the promise object back to the controller that calls the service. The reason for doing this is to remove copy and paste code from my controllers, all of which are getting http resources in the same way and all of which have error handling logic which also is copied and pasted.
The design problem I'm having is I want the error handling logic to be defined in one place and to be usable by any controller. Controllers should be able to request string resources from the service and assign them to the scope like $scope.ButtonText = $myService.resources.ButtonText; and that's ideal because it's just one line of code with no logic. The problem is that if the error handling logic is in the service then I can't (or shouldn't at least) modify the scope from inside the service. What I want is if the error handling logic determines something has gone wrong then it should return an empty string to the controller and set $scope.error to an appropirate error message.
Since I don't want scope manipulation in the service my first and only thought is that I could have the controllers deal with the errors. For instance the call to $myService.resources.ButtonText could return null if there is a problem with the http request and then the controller can assume an error whenever it gets null back. The problem with this is I would have to copy and paste this error handling logic into every controller, undoing my refactoring efforts!
How can I centralize error handling logic in this situation?

Answer 1

So basically anytime there is an http error, rather than a behavior, like forwarding to an error page, you want the particular error available to your controller without having to write a bunch of .success().error() boilerplate in every method.
On thing you might try is broadcasting the error from your service, then you can listen wherever you want. It might be handy to have a service that listens or maybe a controller that deals with providing error feedback on the page.
Maybe a variation of this basic idea:
services.factory('myService', ['$q', '$http', '$rootScope', function( $q, $http, $rootScope){
function getSomething(someID){
$http.get(url).success(function (data) {
deferred.resolve(data);
}).error(function(error) {
$rootScope.$broadcast('http-error', { foo: 'bar' });
deferred.reject(null);
});
Then somewhere, either a controller or a service you inject into a controller you can catch the errors and have access to the information you want:
$rootScope.$on('http-error', function handler(obj) {
//handle error
console.log("error:", obj)
});
If you write this into a service, then you could save the error in the service than it would be available to any controller that injected the service i.e. myErrorService.httpError

Answer 2

to solve this I would use a http interceptor and a http wrapper for the calls.
I'm actually in the process of refactoring this in my app.
Here is the interceptor, to handle http errors and redirect to login page if necessary:
app.factory('errorsInterceptor', ['$rootScope', '$q', '$window', '$location', 'localStorageService', 'Logger', function ($rootScope, $q, $window, $location, localStorageService, Logger) {
return {
response: function (response) {
if (response.status === 401) {
$location.path('/pages/signin');
}
return response || $q.when(response);
},
responseError: function (rejection) {
if (rejection.status === 401) {
$window.sessionStorage.redirectUrl = $location.path();
$location.path('/pages/signin');
}
return $q.reject(rejection);
}
};
}]);
And here is how you can plug it in:
app.config(['$httpProvider', function ($httpProvider) {
$httpProvider.interceptors.push('errorsInterceptor');
}]);
Here is my http wrapper, from which I'll make all the api calls:
(function () {
'use strict';
var serviceId = 'HttpService';
angular.module('app').factory(serviceId, ['$http', '$q', HttpService]);
function HttpService($http, $q) {
var service = {
get: getData,
};
return service;
function getData(url) {
var deferred = $q.defer();
$http.get(url).success(function (data) {
deferred.resolve(data);
}).error(function (error) {
// put your global error handling here, in this case it just returns null as you said
deferred.reject(null);
// you could also return the error message:
// deferred.reject(error.message);
});
return deferred.promise;
}
}
})();
Now an example of how you can use that in your app's controllers:
(function () {
'use strict';
var controllerId = 'ExampleCtrl';
angular.module('app').controller(controllerId,
['$scope', 'HttpService', ExampleCtrl]);
function ExampleCtrl($scope, HttpService) {
HttpService.get('my-endpoint-url').then(function(returnedData){
$scope.title = returnedData;
});
}
})();
With this, "title" gets the value returned from the endpoint in case of success or NULL in case of an error.
To understand this better, I recommend to study promises, here's an useful link:
http://liamkaufman.com/blog/2013/09/09/using-angularjs-promises/
Hope that helps.

Answer 3

Instead of returning a string from your service, return an object with a value and an error property. If there's an error the data will be null and the error will contain the error information which your controller can use however it wants.
For instance, your service can return on error:
{"value":null, "error":"404 Error"}
or on success:
{"value":"My awesome string", "error":null}
Then in your controller you can do something like this:
$scope.foo = val.value || val.error
or something a little nicer that the offers different behavior based on the return.

Answer 4

you need to write an http interceptor....
just an example below
module.factory('timestampMarker', [function() {
var timestampMarker = {
responseError: function(response) {
console.log(response);
toastr.error(response.Message)
return response;
}
};
return timestampMarker;
}]);
module.config(['$httpProvider', function($httpProvider) {
$httpProvider.interceptors.push('timestampMarker');
}]);
you can read this great article on the http interceptors
another article on http interceptor
EDIT (as per comment)
the requirement is to have global error handling mechanism which does return null on any sort of failure in any http call across the application...
httpInterceptor is the place where you can do such global handling of http calls...
e.g. if you get 401/unauthenticated response from server you can to redirect user to login page, or
if you get an error, you can log that error in console or display an alert
so this error handling is implemented for all the http calls, and it keeps you individual http class DRY.
you can use this httpInterceptor to return null for any kind of error in http call response, so then as you said, you dont have to write set to null statement in each http response.
though, my suggestion would be against returning null on all sort of error and let the individual http call take the decision of how to handle error. yes, implement global error handling, but that should only be for errors like 401 error.