mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
e7c770709b
Error-handling in AIO happens mainly in two places: 1. For errors happening inside the app we have a custom `ErrorHandler` implementation, `ReportingErrorHandler`. `ReportingErrorHandler` passes errors to the default `ErrorHandler` (for them to be logged to the console) and also forwards them to `window.onerror()`. 2. Errors happening outside the app and errors forwarded by `ReportingErrorHandler` are handled by `window.onerror()`, which in turn reports them to Google analytics. Previously, we were making some assumptions (which turned out to be incorrect based on the info captured in Google analytics - see #28106): - `ReportingErrorHandler` assumed that the errors passed to its `handleError()` method would be either strings or `Error` instances. _Apparently, other values (such as `null` or `undefined`) may also be passed._ - `window.onerror()` assumed that if an `Error` instance was passed in, it would always have a stacktrace (i.e. its `stack` property would be defined). _This is not necessarily true, although it is not clear (based on the logs) whether reported errors of this type are caused by `Error` instance with no stacktrace or by non-string error objects which are incorrectly treated as `Error` instances. This commit ensures that all types of error arguments can be handled correctly, including `Error` instances with no stacktrace and other types of objects or primitives. NOTE: PR #42881 is related as it fixes handling `null` and `undefined` arguments in the default `ErrorHandler`. Fixes #28106 PR Close #42883 |
||
|---|---|---|
| .. | ||
| app | ||
| assets | ||
| environments | ||
| extra-files | ||
| styles | ||
| testing | ||
| 404-body.html | ||
| custom-elements-es5-polyfills.js | ||
| google385281288605d160.html | ||
| index.html | ||
| main.ts | ||
| noop-worker-basic.js | ||
| polyfills.ts | ||
| pwa-manifest.json | ||
| test.ts | ||