fix(core): Ensure errors in listeners report to the application error…#60251
fix(core): Ensure errors in listeners report to the application error…#60251atscott wants to merge 1 commit intoangular:mainfrom
Conversation
d0b2667 to
547682c
Compare
547682c to
9c4f90f
Compare
… handler Practically speaking, this change ensures that Angular is able to make decisions about what to do when an uncaught error happens. For tests, this will mean that, by default, the error either causes the `fixture.whenStable` promise to reject if there is one or rethrow the error. This ensures tests do not accidentally ignore errors. Opting out of this can be done with the `rethrowApplicationErrors: false` option in `TestBed`. For SSR, there may be additional behaviors in the future that we want to add, such as redirecting to an error page or responding with a 500 status code. BREAKING CHANGE: Uncaught errors in listeners which were previously only reported to `ErrorHandler` are now also reported to Angular's internal error handling machinery. For tests, this means that the error will be rethrown by default rather than only logging the error. Developers should fix these errors, catch them in the test if the test is intentionally covering an error case, or use `rethrowApplicationErrors: false` in `configureTestingModule` as a last resort.
9c4f90f to
9c63777
Compare
|
Green TGP. TGP CL contains 2 local changes that have been sent to reviewers. We can also get global approver during sync if needed (LSC already approved) |
|
I see that you just added the If you want your PR to be merged, it has to pass all the CI checks. If you can't get the PR to a green state due to flakes or broken |
|
This PR was merged into the repository by commit 7b819be. The changes were merged into the following branches: main |
|
I'm really happy Angular may plan to propagate errors to SSR, so it returns e.g. 500 error page. As a contribution, let me share this thought: For example, in our Angular ecommerce meta-framework Spartacus, we've already implemented such a mechanism - we capture errors in our custom global ErrorHandler and propagate it via a custom injectable callback PROPAGATE_ERROR_TO_SERER up to the SSR layer. This injectable was provided on the platform-injector-level by the customized For other feedbacks from our team on the error handling in SSR, feel free to see the historical discussions in those Angular issues/PRs:
Again, many thanks for your long-term willingness to improve error handling in SSR 🙌 |
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
… handler
Practically speaking, this change ensures that Angular is able to make decisions about what to do when an uncaught error happens.
For tests, this will mean that, by default, the error either causes the
fixture.whenStablepromise to reject if there is one or rethrow the error. This ensures tests do not accidentally ignore errors. Opting out of this can be done with therethrowApplicationErrors: falseoption inTestBed.For SSR, there may be additional behaviors in the future that we want to add, such as redirecting to an error page or responding with a 500 status code.
BREAKING CHANGE: Uncaught errors in listeners which were previously only reported to
ErrorHandlerare now also reported to Angular's internal error handling machinery. For tests, this means that the error will be rethrown by default rather than only logging the error. Developers should fix these errors, catch them in the test if the test is intentionally covering an error case, or userethrowApplicationErrors: falseinconfigureTestingModuleas a last resort.