Angular: Default handler for unhandled http errors

Question

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
]

Answer 1

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.