Wouldn’t it be great if everything always just worked? That we never had a runtime error… That the server-side Web services were always available and worked? But we know that is not the case. Things go wrong.

The most common ways to handle exceptions in an Angular application are:

• With a JavaScript try/catch block
• You can add a try/catch block around code that could fail
• That allows you to catch specific errors and handle them appropriately.
• You can use the Angular global exception handler
• Angular has a built-in service, called $exceptionHandler, that catches exceptions
• By decorating this service, you can tailor it to the needs of your application.
• When working with promises, you can also add failure or catch functions

This post covers the second option, using the Angular global exception handler.

If you are interested in more information, I cover exception handling in detail in my Pluralsight course: “AngularJS Line of Business Applications“.

Decorating $exceptionHandler

Angular provides a built-in global exception handling service called $exceptionHandler. Any uncaught exception is delegated to this service. This service only catches exceptions, not communication errors (such as 404 not found) or syntax errors.

The default implementation of $exceptionHandler logs any exceptions to the browser console. You can change this functionality by decorating the $exceptionHandler service.

Say we wanted to change the default global exception handler to display a message to the user. We could accomplish this by decorating the $exceptionHandler service as shown in the code below:

• Line 14:
• The above code configures the application with a decorator.
• The code needs the Angular built-in $provide service, so it is passed as a parameter to the configuration function.
• Line 15:
• The $provide service is used internally as part of Angular’s component registration process.
• The decorator method of this service can intercept requests and provide different or additional functionality.
• The decorator method takes two parameters:
• The first parameter is the string name of the service being decorated. In this case, it is the $exceptionHandler service.
• The second parameter is a min-safe array containing the name of each decorator function parameter and then the decorator function itself.
• Line 16:
• The decorator function has a dependency on $delegate. So $delegate is listed in the min-safe array.
• $delegate provides the original service to the method. This allows you to call the base implementation of that service.
• Line 17:
• $delegate is passed as a parameter to the decorator function.
• Line 18:
• This method returns a decorated $exceptionHandler service object.
• The returned function has two parameters: the exception and the cause.
• Line 19+20:
• In this example, the code in the returned function replaces the exception message with a custom message.
• Line 21:
• Then it uses $delegate to call the base implementation of the service.
• The base implementation simply logs the error to the console.
• Line 22
• Lastly, this code adds an alert to notify the user of the issue.

Now, any time that an unhandled exception occurs, the message is logged to the console (the default behavior) *and* the user is notified with an alert.

You can add anything you need to this function. For example, you may want to add more extensive logging or a more detailed message.

Enjoy!