Possible unhandled rejection

[rekna1]

Since upgrading from 1.5.x to 1.6.1 I'm getting 'Possible unhandled rejection' errors on $http requests, even though I have a global httpinterceptor which catches errors (showing a dialog with the error message).

I've read about the reason for this error, but it seems to do more harm than good.
And the stack trace does not give any clue to where the error occurs (all lines point to code in angular.js).

I would rather not have to add an error handling method to each .then portion, it's unnecessary bloat.

Maybe I'm not handling the errors in the correct way in my global http interceptor ( according to what 1.6.1 expects), but fact is that before 1.6 this was working without errors.

Maybe you could provide an example of how errors should be handled correctly with a global http interceptor?

[zdenekhatak]

Hi, are you using ui-router? If you are, try updating - angular-ui/ui-router#3120

[gkalpak]

The error messages should be better in 1.6.2 (thanks to #15527), but it is a documented breaking change and you'll have to deal with it one way or another. (Note that it is even possible to silence these errors via $qProvider.errorOnUnhandledRejections(false), restoring the previous behavior.)

In any case, we can't do much without a reproduction of the issue. I am going to close, since everything works as expected (afaict), but feel free to continue the discussion below.

[rekna1]

In your example, by returning a string from the error handler, the success handler of the then function will be called, which is not what I want.
How would I code error handler to handle such case in generic way:
In case of http status 200 execute success part of the ten function
In case of error display message and do not execute success part. If an error handler exist execute it, if not no error in console.

[gkalpak]

I don't know what example you are talking about, but this sounds like a general support question, so please use one of the appropriate support channels.
_{GitHub issues are reserved for bug reports and feature requests.}

[rekna1]

The one you gave in codepen https://codepen.io/ExpertSystem/pen/BpKjaZ?editors=0012

[gkalpak]

Oh, I gave one 😃

So, if your responseError interceptor doesn't return a rejection (i.e. recovers from the error), then the success callback will be called as if the request never errored. If your interceptor returns a rejection (e.g. return $q.reject(error)), then the promise returned by $http will be treated as rejected (i.e. the error handler will be called or a Possibly Unhandled Rejection error will be logged).

The only way to silence the Possibly Unhandled Rejection without providing an error handler is via $qProvider.errorOnUnhandledRejections(false).

[lukengda]

Is there a new status on this issue?

I want to achieve the same behavior. Can i somehow set the errorOnUnhandledRejections flag for the one promise during return $q.reject(error)?