Menu
In my angularjs app, I defined a default handler for http errors this way:
myapp.config([ '$httpProvider', function($httpProvider) {
$httpProvider.responseInterceptors.push('errorInterceptor')
}])
where errorInterceptor is a service that displays some details about the error in an alert field on the top of the current page.
Now, when I want to handle a specific error in a different way (say the query is triggered in a modal, and I want to display the alert only in this modal, and not at page level):
$http.get('/my/request').then(success, specificErrorHandling)
Angular does the specificErrorHandling but still triggers my errorInterceptor, so my error gets reported twice. Is there a way to avoid that?
More generically, is there an Angular way to handle only errors that aren't already taken care of along the promise chain, the same way the top-level error handler of a server app doesn't have to handle catched exceptions?
Edit: As requested by Beetroot-Beetroot in comments, here is the code for my interceptor:
@app.factory 'errorInterceptor', [ '$q', 'alertsHandler',
($q, alertsHandler) ->
success = (response) ->
response
failure = (response) ->
alertsHandler.raise(response)
(promise) ->
promise.then success, failure
]
626
When the error occurs in the HTTP Request it is intercepted and invokes the catchError . Inside the catchError you can handle the error and then use throwError to throw it to the service. We then register the Interceptor in the Providers array of the root module using the injection token HTTP_INTERCEPTORS .
One traditional way of handling errors in Angular is to provide an ErrorHandler class. This class can be extended to create your own global error handler. This is also a useful way to handle all errors that occur, but is mostly useful for tracking error logs.
Angular 2 applications have the option of error handling. This is done by including the ReactJS catch library and then using the catch function. Let's see the code required for error handling. This code can be added on top of the chapter for CRUD operations using http.
ErrorHandlerlink Provides a hook for centralized exception handling.
We have something like that.
If we handle the http error, we pass a property on the request called errorHandled:true
$http({
method: 'GET',
url: '/my/url',
errorHandled:true
}).then(function(){ ... }, function(){ ... });
And then in the intercept for responseError: function(rejection){ ... } we can see if this flag is set by looking at rejection.config.errorHandled and if not - then we pop a toastr dialog with the error. the code looks something like this
function ( rejection ) {
if ( !rejection.config.errorHandled && rejection.data.message ){
toastr.error(rejection.data.message, 'Error');
}
return $q.reject(rejection);
}
The chances of someone writing "errorHandled:true" without adding a handler are slim. The chances of having 2 error indicators are also slim because we got used to it - but actually 2 indicators are better than none..
It would be great if we had the promise to query it if it has an error handler or not down the then chain, but we couldn't find this anywhere.
73
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
