angular: Change detection stops working after uncaught exception occurs during the binding evaluation in prod mode

I’m submitting a …

[X] bug report
[ ] feature request

Current behavior

In prod mode, change detection stops working after uncaught exception occurs during the binding evaluation.

Details: the subscription to zone.onMicrotaskEmpty event, which is established in angular/core/application_ref is being unsubscribed automatically by RxJS (at SafeSubscriber.__tryOrUnsub), when uncaught exception occurs during the binding evaluation, and currently there s no way to recover from uncaught exception during the binding evaluation in prod mode.

Expected/desired behavior

In prod mode, change detection should continue to function properly after uncaught exception during the binding evaluation.

Reproduction of the problem

http://plnkr.co/edit/2fe6GC6NkuFkffpEoDPZ?p=preview

What is the motivation / use case for changing the behavior?

In our project, which previously used angular beta 9, we’ve built custom error handling (by subsclassing ExceptionHandler). When in prod mode, the error was displayed in a popup on the current page, with ‘Report’ button, and other stuff. After upgrading the project to RC1, we’re unable to display the popup on the current page after the uncaught error has occurred.

There should be some ability to recover from an uncaught exception.

Please tell us about your environment:

  • Angular version: 2.0.0-rc.1 - 2.0.0-rc.3
  • Browser: all
  • Language: all

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 4
  • Comments: 21 (4 by maintainers)

Commits related to this issue

Most upvoted comments

Still the same on 2.0.x

This is a problem when a template expression causes the exception, because there is no real way to catch it (as far as I know).

https://plnkr.co/edit/T1JccPu4ctADmM6f1sPa

I understand that in a lot of cases this would be due to the code not being defensive enough, but nobody wants to rely upon ultra defensive coding. I think the use case from the OP is absolutely valid.