Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

Possible unhandled rejection  #15599

Description

@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?

Activity

  1. zdenekhatak commented on Jan 11, 2017

    @zdenekhatak

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

  2. gkalpak commented on Jan 11, 2017

    @gkalpak
    Member

    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.

  3. rekna1 commented on Jan 17, 2017

    @rekna1
    Author

    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.

  4. gkalpak commented on Jan 17, 2017

    @gkalpak
    Member

    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.

  5. rekna1 commented on Jan 17, 2017

    @rekna1
    Author
  6. gkalpak commented on Jan 17, 2017

    @gkalpak
    Member

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

  7. lukengda commented on Aug 28, 2017

    @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)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions