Throwing from $exceptionHandler breaks the digest loop leaving it in a zombie state.

[d-ph]

Do you want to request a feature or report a bug?
Bug

What is the current behavior?
When the $exceptionHandler is overridden to throw the thrown exceptions, then the digest loop is sometimes left in a zombie state (i.e. the clearPhase(); is not called).

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem via https://plnkr.co or similar (template: http://plnkr.co/edit/tpl:yBpEi4).
I tried to create a minimal demo of the bug, but I was unable to reproduce it.

What is the expected behavior?
The digest loop is operational after the exceptions are thrown (i.e. the clearPhase(); is called before leaving the loop).

What is the motivation / use case for changing the behavior?
I'd like the javascript Errors to be thrown instead of being logged to the console. I have a custom error handler set up on the window.onerror event. Errors don't trigger this event, when thrown from angular context (they are logged to the console instead, as per default $exceptionHandler behaviour)

Which versions of Angular, and which browser / OS are affected by this issue? Did this work in previous versions of Angular? Please also test with the latest stable and snapshot (https://code.angularjs.org/snapshot/) versions.
Tested against version: AngularJS v1.5.7-build.4839+sha.a478f69

Other information (e.g. stacktraces, related issues, suggestions how to fix)

// angular.js

      $apply: function(expr) {
        try {
          beginPhase('$apply');
          try {
            // (1)
            return this.$eval(expr);
          } finally {
            clearPhase();
          }
        } catch (e) {
          $exceptionHandler(e);
        } finally {
          try {
            // (2)
            $rootScope.$digest();
          } catch (e) {
            $exceptionHandler(e);
            throw e;
          } finally {
              // (3)
              // clearPhase();
          }
        }
      },

If I add a finally block with a clearPhase(); at position (3), then the digest loop is properly cleaned up in a case of an error being thrown. I tried to create a small demo of this problem, but somehow the demo code throws from the this.$eval(expr)(1), while the code I'm working on is throwing from the $rootScope.$digest()(2). As you can see, when errors are thrown from the (1), then the clearPhase(); is called.

This is probably related with these two PRs:

1. link
2. link

The second PR would probably fix the problem, because it adds a giant try..finally block in the .$digest() method. It wasn't merged though.

For now, I'm throwing Errors from my $exceptionHandler using a setTimeout() function, so Angular has an opportunity to get out of the digest loop with a proper clean up.

[gkalpak]

As discussed in #13184, throwing from the $exceptionHandler will leave the app in an inconcistent state (with or without clearPhase()). What is your usecase ? Why do you need an error to be thrown ?

[d-ph]

In short: I'd like the errors to be thrown, because I'd like the window.onerror event to be fired.

Slightly longer reasoning: I propagate errors in my application in such a way, that any intermediate stacks in the stack trace can decide to catch the error and recover from it or perform some intermediate cleanup and rethrow. That's why I never use $exceptionHandler. Instead I just throw a custom AppError class as I normally would (or reject a promise with this custom error class, if I am in a promise chain), and then listen on the window.onerror event. If my window.onerror event listener caught an instance of my custom AppError class, then I show a popup with a message (I also distinguish user-displayable errors and generic errors, but that's beside the point). This setup allows me to show the popup knowing, that none of the intermediate stacks in the call stack wanted to recover from this error.

I need to throw from the $exceptionHandler, so my AppErrors thrown from angular context aren't "swallowed" by the default $exceptionHandler.

If throwing from the $exceptionHandler is discouraged, then why this is mentioned in official docs: link?

[d-ph]

I actually agree, that hard-throwing from the $exceptionHandler is probably not a good idea. Not because this would leave the app in inconsistent state, but because angular and angular ecosystem generally assume, that $exceptionHandler doesn't throw back. We would fix that in the digest loop, but there are still numerous places in angular and angular plugins, that, well, do different sorts of cleanup after passing errors to the $exceptionHandler. I'm kind of happy with using my setTimeout()/_.defer() method to throw from the $exceptionHandler to play nicely with the community. But maybe at least the official docs should stop recommending/mentioning hard-throwing from the $exceptionHandler. Even better: maybe the docs should actually say, that $exceptionHandler must not throw back?

[gkalpak]

I don't see where we recommend hard-throwing in the docs. The only mention of hard-throwing is in the context of unit-testing (where it makes sense). I'll add a clarification though.

[d-ph]

Thanks 👍