Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsAngular sends errors it catches in framework-managed application code to the root ErrorHandler, but it does not automatically catch every error your application throws. Handle expected, recoverable failures at the callsite, where you can decide whether to retry or show a useful state; use global handling mainly to report unexpected failures. Browser, server-side rendering, routing, and rendering-boundary errors each have distinct handling paths.
Which errors does Angular catch?
Angular catches errors while invoking application code through framework-managed flows, including component construction and lifecycle methods. Those caught errors are forwarded to the root ErrorHandler. This is not a blanket catch around all application code: a service method called directly by your code is not automatically wrapped in an Angular catch.
As an Amazon Associate I earn from qualifying purchases.
The practical rule is to handle a failure where the operation is called if that code has enough context to recover. Angular’s official Unhandled errors in Angular guide says errors should be surfaced to developers at the callsite whenever possible. A global handler can report an unexpected failure, but usually cannot decide whether a particular request should be retried or what fallback makes sense to the user.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →How should I handle errors at the callsite?
Synchronous operations
Use try...catch around a synchronous operation when the caller can take meaningful action:
#1 Best Overall
try {
saveDraft();
} catch (error) {
showSaveFailure();
reportUnexpectedError(error);
}Choose recovery based on the operation: preserve user input, offer a retry, or show a relevant failure state. Do not use a catch merely to silence an error if the application cannot continue safely.
Observable flows
For an Observable, use an operator such as RxJS catchError where the caller can select a fallback or expose an error state. This keeps recovery logic alongside the operation whose result the UI or business logic needs. Angular recommends local handling or suitable operators instead of relying on ErrorHandler for expected failures.
How do asynchronous errors reach ErrorHandler?
Angular forwards asynchronous errors when it has an explicit contract to wait for and use a result, and the failure is not already represented in returned state. For example, errors from AsyncPipe and PendingTasks.run are forwarded to ErrorHandler.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Other APIs communicate failure as state rather than forwarding it. A resource exposes its failure through its status and error properties. Read and handle those properties in the code that consumes the resource; do not assume every rejected asynchronous operation will be delivered to the global handler.
Rank #3
How do I handle errors globally in a browser app?
provideBrowserGlobalErrorListeners() registers listeners for browser error and unhandledrejection events and forwards them to Angular’s ErrorHandler. Angular’s guide says the CLI includes this provider by default in new applications. Check the configuration generated for your project and its Angular version before adding it; avoid duplicating equivalent custom listeners.
The provider is useful for centralized reporting of browser-global failures, not as a replacement for handling expected errors where they occur. The API details are in Angular’s provideBrowserGlobalErrorListeners reference.
What changes with server-side rendering?
For server-side rendering, Angular adds unhandledRejection and uncaughtException listeners to the server process and logs captured errors to the console. When Zone.js is in use, Angular adds only the unhandledRejection process handler because errors inside the application zone are already forwarded to ErrorHandler. Browser global listeners are therefore not the only global error mechanism to consider in an SSR application.
How do rendering error boundaries work?
Angular’s @boundary and @error rendering features can display fallback UI for errors during initialization or change detection, support reset, and conditionally select fallbacks. Angular marks this feature as developer preview; verify its status and availability in the Angular version used by your project before adopting it in production. See the official Error boundaries with @boundary guide.
Place the boundary where the content is declared
A boundary around ng-content does not catch errors from projected content. Put the boundary where that content is declared instead. Boundary errors may also be reported through a custom handler’s onViewError hook.
How should I handle router and resolver failures?
Route resolver failures and navigation errors have router-specific handling options. Angular documents three approaches: configure withNavigationErrorHandler, subscribe to router events, or handle the failure inside the resolver. Choose based on whether the response belongs to centralized navigation policy or to the particular data the resolver is loading. The official Route data resolvers guide describes these options.
Why do tests or startup errors behave differently?
TestBed rethrows unexpected errors
TestBed rethrows unexpected application errors by default so a test fails visibly instead of silently passing. Keep that behavior for ordinary tests; disable or alter it only when a test is specifically checking that the application remains resilient to an error.
Recommended Free Tools
Errors before the root instance exists
An error that occurs before Angular has created the root instance cannot yet be sent to a provided ErrorHandler. Angular notes this can happen when defining an Angular element whose tag is already present on the page. A root-level handler cannot cover failures that happen before it exists.
Quick Recap
Where should each kind of failure be handled?
| Where or how the failure occurs | Preferred handling | What to know |
|---|---|---|
| Direct synchronous call | try...catch at the callsite |
The caller can decide whether to recover, retry, or show an error state. |
| Observable operation | An operator such as catchError at the callsite |
Use it when the caller can choose recovery or a fallback. |
| Framework-managed application code | Root ErrorHandler |
Angular forwards errors it catches in framework-managed flows; this does not cover every direct call. |
Browser-global error or unhandledrejection |
provideBrowserGlobalErrorListeners(), then ErrorHandler |
Check whether the project’s CLI setup already includes the provider. |
| Resource failure | Read the resource’s status and error |
The failure is exposed as state rather than necessarily forwarded. |
| Server-side rendering process failure | Angular’s server process listeners and logging | Behavior differs when Zone.js is in use. |
| Initialization or change-detection rendering failure | @boundary fallback, if appropriate |
Developer preview; projected content must be bounded where it is declared. |
| Resolver or navigation failure | withNavigationErrorHandler, router events, or resolver-local handling |
Use the router’s documented failure paths. |
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
