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

[angular 1.5.4] $onChanges hook will not be called if an exception is thrown #14444

Closed
bogdanalexe90 opened this issue Apr 15, 2016 · 6 comments

Comments

@bogdanalexe90
Copy link

Note: for support questions, please use one of these channels: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#question. This repository's issues are reserved for feature requests and bug reports.

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

What is the current behavior?
I have 2 components, both using $onChanges. If one of them is throwing an exception the $onChanges hook is not called anymore for the next changes.

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

http://plnkr.co/edit/wLXecrKvw2u4RFV6wmmp?p=preview

What is the expected behavior?

The $onChanges hook should be called every time there is a change.

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

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.

angular 1.5.4 and angular 1.5.3

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

@Narretz
Copy link
Contributor

Narretz commented Apr 18, 2016

@petebacondarwin can you take a look at this?

I can say that the problem doesn't come from the fact that there are two components. One is enough. And somehow, throwing in an onChange fn throws off (heh) the change queue flushing.

@petebacondarwin
Copy link
Contributor

OK. This is a valid bug. The question is what do want to do when any of the hooks throw errors?

@petebacondarwin petebacondarwin self-assigned this Apr 18, 2016
@petebacondarwin petebacondarwin modified the milestones: 1.5.5, 1.5.6 Apr 18, 2016
@petebacondarwin
Copy link
Contributor

The plan is to have the same behaviour to watch handlers. We should catch the error and recover the rest of the application.

petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then any other `$onChanges`
hooks that had been scheduled were not executed, nor was the queue cleaned up
properly.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then any other `$onChanges`
hooks that had been scheduled were not executed, nor was the queue cleaned up
properly.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously.

Closes angular#14444
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then any other `$onChanges`
hooks that had been scheduled were not executed, nor was the queue cleaned up
properly.

Closes angular#14444
Closes angular#14463
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously.

Closes angular#14444
Closes angular#14463
petebacondarwin added a commit to petebacondarwin/angular.js that referenced this issue Apr 19, 2016
Previously, if one of these hooks threw an error, then any other `$onChanges`
hooks that had been scheduled were not executed, nor was the queue cleaned up
properly.

Closes angular#14444
Closes angular#14463
petebacondarwin added a commit that referenced this issue May 27, 2016
Previously, if one of these hooks threw an error, then the compilation
was terminated unceremoniously. In particular any other `$onChanges`
hooks that had been scheduled were not executed, nor was the queue cleaned
up properly.

Closes #14444
Closes #14463
@vippatel90
Copy link

vippatel90 commented Nov 28, 2018

so this is fixed in which version? Still happening in 1.5.11. Once onChanges fn throws any error while running(life cycle), OnChange stops listening next changes. it flushes change queue.

@petebacondarwin
Copy link
Contributor

The commit that fixes this issue shows that it appears on 1.6.0-rc.0 onwards: de54480

@gkalpak
Copy link
Member

gkalpak commented Nov 28, 2018

Interestingly, it was also merged into the 1.5.x branch (3749c85), but never included in a 1.5.x released.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants