title: Best practices for handling HTTP errors in Angular - Http interceptor or individual error handlers
body: <p>I'm debating different ways to handle errors in my Angular app. I've already implemented error handling in one way, but I'm starting to see potential holes and problems that might be an issue further down the road. I've considered another option, but I'm not sure which would be more appropriate in an Angular best practice context. I'll explain them both below.</p>
  
  <p>1) The first, currently implemented manner of handling errors involves making use of the error handler within http request subscriptions. I have separate services that handle http requests for a particular module of the app, and classes subscribe to the observables exposed by the methods of these http classes. Within the subscription I use the error handler to catch the error and push the details of the error to a GenericErrorService class that in turns emits the details via a subject which the UI component can subscribe to and act accordingly (display snackbar with error details etc). </p>
  
  <pre><code>doSomething() {
      this._httpService.doHttp$().subscribe(
        (result) =&gt; {
          //do stuff with successful result
        },
        error =&gt; {
          this._genericErrorService.emitErrorDetails(GenericErrorType.SpecificError, error.status);
        }
      );
    }
  </code></pre>
  
  <p>The GenericErrorService takes an enum as a parameter that reflects the type of error that has occurred. This is particularly useful to the UI component as it allows to check which type of error has occurred and act in an appropriate way. Since this subscription error handler is written for a specific http request, we can be sure of the type of error that has occurred.</p>
  
  <p>However this method of handling errors means that there are many http error handlers within my service (and other services) meaning there is a lot of code to maintain and that could possibly conflict with each other. In addition, race conditions between http requests that are being sent at the same time and returned at different times means that this particular method is causing the UI elements that display the errors to flicker due to the errors being returned and overwriting whatever element is displayed at the time. This code works for the current application, but extend-ability is a big concern, hence why I'm considering other options. </p>
  
  <p>2) The other option I am considering is to use a HTTP interceptor class to track all of the incoming errors via catchError and to act appropriately according to the error that has been received. </p>
  
  <pre><code>  intercept(request: HttpRequest&lt;any&gt;, next: HttpHandler): Observable&lt;HttpEvent&lt;any&gt;&gt; {
  
      return next.handle(request).pipe(
        catchError((error: HttpErrorResponse) =&gt; {
          //determine which error has occurred, emit error details to GenericErrorService
          return throwError(error.message);
        })
      );
    }
  }
  </code></pre>
  
  <p>The use of a HTTP interceptor means that I would have a single class concerned with the handling of all errors that can occur within the app, obviously meaning that maintenance and extend-ability is far greater. However by using an interceptor I lose the specificity that is offered by having a single error handler for each http response. Since the interceptor will catch all errors, I'd no longer be able to push a specific <code>GenericErrorType</code> to the GenericErrorService, instead I'd have to do some kind of check to see exactly which error has occurred and then act upon that. The only way I can think of doing this would be to do string comparisons against the url held inside the <code>HttpErrorResponse</code>, which again gives me concerns of maintenance in-case the API urls change, thus breaking the app's error handling.</p>
  
  <p>Which would be the better option here?</p>