What are advanced RxJS error handling patterns?
Robust error handling is crucial for building resilient Angular applications. While basic `catchError` is a good start, advanced RxJS patterns allow for more sophisticated, user-friendly, and maintainable ways to deal with errors in asynchronous streams. This guide explores several advanced techniques to enhance your application's stability and user experience.
Understanding the Foundation: `catchError`
At the core of most RxJS error handling lies the catchError operator. It intercepts an error notification from an observable, performs an action, and then returns a new observable. The way you construct this new observable determines the error handling pattern.
Catch and Replace (with a default value or alternative stream)
This pattern is used when you want to gracefully recover from an error by providing a default value or an alternative data stream. The original observable sequence terminates, but the subscriber receives the replacement value(s) instead of an error.
import { of, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';
interface Product { id: number; name: string; price: number; }
// Simulate a service call that might fail
const getProductById = (id: number) => {
if (id === 1) {
return of({ id: 1, name: 'Laptop', price: 1200 });
} else if (id === 2) {
return throwError(() => new Error('Product not found!'));
} else {
return of({ id: id, name: `Product ${id}`, price: 50 });
}
};
const defaultProduct: Product = { id: 0, name: 'Unknown Product', price: 0 };
getProductById(2).pipe(
catchError(error => {
console.error('Error fetching product, returning default:', error.message);
return of(defaultProduct); // Replaces the erroring stream with a default value
})
).subscribe({
next: product => console.log('Received product:', product),
error: err => console.error('This should not be called:', err) // Will not be called
});
// Output:
// Error fetching product, returning default: Product not found!
// Received product: { id: 0, name: 'Unknown Product', price: 0 }Catch and Rethrow (logging and propagating)
Sometimes you need to perform a side effect (like logging the error) and then rethrow the error so that it continues to propagate up the observable chain. This allows higher-level error handlers or the global Angular ErrorHandler to catch it, ensuring no error goes unnoticed while still performing local cleanup or logging.
import { throwError, timer } from 'rxjs';
import { catchError, mergeMap } from 'rxjs/operators';
const failingObservable = timer(100).pipe(
mergeMap(() => throwError(() => new Error('Service Unavailable')))
);
failingObservable.pipe(
catchError(error => {
console.error('Local handler: An error occurred:', error.message);
return throwError(() => new Error('Propagated: ' + error.message)); // Rethrow the error
})
).subscribe({
next: data => console.log('Data:', data),
error: err => console.error('Global handler/Subscriber:', err.message) // This will be called
});
// Output:
// Local handler: An error occurred: Service Unavailable
// Global handler/Subscriber: Propagated: Service UnavailableRetrying Operations with `retry` and `retryWhen`
When dealing with transient errors (e.g., network glitches, temporary server overload), retrying an operation can often lead to success without user intervention. RxJS offers retry for simple retries and retryWhen for highly customized retry logic.
Simple `retry()`
The retry(count) operator resubscribes to the source observable a specified number of times if an error occurs. If all retries fail, the error is then passed down the stream.
import { throwError, timer } from 'rxjs';
import { mergeMap, retry, tap } from 'rxjs/operators';
let attempt = 0;
const flakyRequest = timer(500).pipe(
mergeMap(() => {
attempt++;
if (attempt < 3) {
console.log(`Attempt ${attempt}: Failing...`);
return throwError(() => new Error('Transient error'));
} else {
console.log(`Attempt ${attempt}: Succeeding!`);
return of('Data fetched successfully');
}
})
);
flakyRequest.pipe(
retry(2), // Retries 2 times before giving up (total 3 attempts)
tap(null, error => console.error('Final error after retries:', error.message))
).subscribe(data => console.log(data));
// Output:
// Attempt 1: Failing...
// Attempt 2: Failing...
// Attempt 3: Succeeding!
// Data fetched successfullyAdvanced `retryWhen()` (with Exponential Backoff)
retryWhen provides an observable of errors. You can then apply any RxJS operators to this error stream to control when and how the original observable should be re-subscribed. A common pattern is exponential backoff, where retry delays increase with each failed attempt, preventing overwhelming the server.
import { timer, throwError, of, Observable } from 'rxjs';
import { mergeMap, retryWhen, delay, take, tap } from 'rxjs/operators';
const maxRetries = 3;
let retryAttempt = 0;
const dataServiceCall = new Observable<string>(observer => {
retryAttempt++;
if (retryAttempt < 4) {
console.log(`Service Call: Attempt ${retryAttempt} - Failing...`);
observer.error(new Error(`Service error on attempt ${retryAttempt}`));
} else {
console.log(`Service Call: Attempt ${retryAttempt} - Succeeding!`);
observer.next('Successful Data');
observer.complete();
}
});
dataServiceCall.pipe(
retryWhen(errors => errors.pipe(
mergeMap((error, i) => {
const retryCount = i + 1;
if (retryCount > maxRetries) {
// Max retries exceeded, rethrow the error
return throwError(() => new Error(`Max retries (${maxRetries}) exceeded: ${error.message}`));
}
const delayMs = Math.pow(2, retryCount) * 100; // Exponential backoff: 200ms, 400ms, 800ms
console.log(`Retrying after ${delayMs}ms for attempt ${retryCount}...`);
return timer(delayMs); // Delay before resubscribing
})
))
).subscribe({
next: data => console.log('Data received:', data),
error: err => console.error('Final subscription error:', err.message)
});
// Expected Output (delays will vary based on timer):
// Service Call: Attempt 1 - Failing...
// Retrying after 200ms for attempt 1...
// Service Call: Attempt 2 - Failing...
// Retrying after 400ms for attempt 2...
// Service Call: Attempt 3 - Failing...
// Retrying after 800ms for attempt 3...
// Service Call: Attempt 4 - Succeeding!
// Data received: Successful DataError Boundaries and Global Handling
While catchError handles errors within an observable stream, some errors might slip through or originate outside RxJS streams (e.g., component lifecycle errors, template errors). Angular provides mechanisms for global error handling.
Angular's `ErrorHandler`
Angular's ErrorHandler service acts as a global fallback for unhandled exceptions that occur anywhere in the application. By default, it just logs to the console. You can provide a custom implementation to send errors to a logging service, display a user-friendly error page, or perform other actions.
// src/app/custom-error-handler.ts
import { ErrorHandler, Injectable } from '@angular/core';
@Injectable()
export class CustomErrorHandler implements ErrorHandler {
handleError(error: any) {
console.error('App-wide Error:', error);
// Log to a remote service
// this.errorLoggingService.logError(error);
// Display a user-friendly modal or redirect to an error page
// this.router.navigate(['/error']);
}
}
// src/app/app.module.ts
import { NgModule, ErrorHandler } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { CustomErrorHandler } from './custom-error-handler';
import { AppComponent } from './app.component';
@NgModule({
imports: [BrowserModule],
declarations: [AppComponent],
providers: [
{ provide: ErrorHandler, useClass: CustomErrorHandler }
],
bootstrap: [AppComponent]
})
export class AppModule { }Conditional Error Handling within Streams
When you have complex Observable pipelines, especially with operators like mergeMap, switchMap, or concatMap that create inner observables, an error in an inner observable can terminate the entire outer stream. You can prevent this by placing catchError inside the mapping function to handle errors only for the inner observable.
import { of, from, throwError } from 'rxjs';
import { mergeMap, catchError } from 'rxjs/operators';
const userIds = from([1, 2, 3, 4]); // Stream of user IDs
const getUserProfile = (id: number) => {
if (id === 3) {
return throwError(() => new Error(`Failed to get profile for user ${id}`));
} else {
return of(`Profile for user ${id}`);
}
};
userIds.pipe(
mergeMap(id => getUserProfile(id).pipe(
catchError(error => {
console.warn(`Handling error for user ${id}: ${error.message}`);
return of(`Default profile for user ${id}`); // Return a default for this user
})
))
).subscribe({
next: data => console.log(data),
error: err => console.error('Outer stream error (should not happen):', err)
});
// Output:
// Profile for user 1
// Profile for user 2
// Handling error for user 3: Failed to get profile for user 3
// Default profile for user 3
// Profile for user 4Notification Pattern (Centralized Error Reporting)
Instead of each catchError block directly showing a toast or logging, you can emit error events to a centralized error service using a Subject or BehaviorSubject. This service can then decide how to present the error to the user (e.g., toast, dialog, console log), decoupling error presentation from the data fetching logic.
// src/app/services/error-notification.service.ts
import { Injectable } from '@angular/core';
import { Subject, Observable } from 'rxjs';
interface AppError {
message: string;
status?: number;
context?: string;
}
@Injectable({ providedIn: 'root' })
export class ErrorNotificationService {
private errorSubject = new Subject<AppError>();
public readonly errors$: Observable<AppError> = this.errorSubject.asObservable();
notify(error: AppError) {
console.log('Notifying of error:', error);
this.errorSubject.next(error);
}
}
// src/app/services/data.service.ts (Example usage)
import { HttpClient } from '@angular/common/http';
import { Injectable } from '@angular/core';
import { Observable, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';
import { ErrorNotificationService } from './error-notification.service';
@Injectable({ providedIn: 'root' })
export class DataService {
constructor(private http: HttpClient, private errorNotifier: ErrorNotificationService) {}
fetchData(): Observable<any> {
return this.http.get('/api/data').pipe(
catchError(httpError => {
const appError: AppError = {
message: `Failed to fetch data: ${httpError.message || 'Unknown error'}`,
status: httpError.status,
context: 'DataService.fetchData'
};
this.errorNotifier.notify(appError);
return throwError(() => appError); // Re-throw if you still want the original stream to error
})
);
}
}
// src/app/app.component.ts (or any component to display errors)
import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';
import { ErrorNotificationService } from './services/error-notification.service';
@Component({ /* ... */ })
export class AppComponent implements OnInit, OnDestroy {
private errorSubscription: Subscription;
public currentError: string | null = null;
constructor(private errorNotifier: ErrorNotificationService) {}
ngOnInit() {
this.errorSubscription = this.errorNotifier.errors$.subscribe(error => {
this.currentError = `Error: ${error.message} (Status: ${error.status || 'N/A'})`;
// Display a toast or modal here
// For demo purposes, just setting a property
console.error('AppComponent received error notification:', error);
});
}
ngOnDestroy() {
if (this.errorSubscription) {
this.errorSubscription.unsubscribe();
}
}
}Best Practices Summary
- Localize
catchError: PlacecatchErroras close as possible to the source of the error to handle it at the most granular level. - Use
retryfor transient errors: ImplementretryorretryWhenfor operations that are prone to temporary failures (e.g., network issues). - Implement
retryWhenwith care: Custom retry logic, especially exponential backoff, prevents overwhelming servers during outages. - Leverage Angular's
ErrorHandler: Provide a customErrorHandlerfor global, unhandled exceptions that escape RxJS streams. - Adopt a Notification Pattern: Centralize error messaging to decouple error presentation from business logic and improve consistency.
- Distinguish between recoverable and unrecoverable errors: Use
catchErrorto recover where possible, and rethrow or allow errors to propagate for critical failures. - Provide meaningful user feedback: Always inform the user about what went wrong, especially for errors that can't be automatically recovered from.