catchError for error handling in Angular - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ component_behavior

intermediate

What happens when catchError returns EMPTY in an Angular service?

Consider an Angular service method that uses catchError(() => EMPTY). What will the subscriber receive if an error occurs?

Angular

import { EMPTY } from 'rxjs';
import { catchError } from 'rxjs/operators';

this.http.get('/api/data').pipe(
  catchError(() => EMPTY)
).subscribe({
  next: data => console.log('Data:', data),
  error: err => console.log('Error:', err),
  complete: () => console.log('Completed')
});

A The subscriber receives no data, no error, and the observable completes silently.

B The subscriber receives an empty array as data and completes.

C The subscriber receives an error notification with the original error.

D The subscriber receives undefined as data and continues listening.

💡 Hint

Think about what EMPTY observable does in RxJS.

The EMPTY observable emits no items and immediately completes. Using catchError(() => EMPTY) swallows the error and completes the stream silently without emitting data or error.

📝 Syntax

intermediate

Identify the correct catchError usage to return a fallback value

Which option correctly uses catchError to return a fallback observable emitting the string 'fallback' on error?

Angular

import { of } from 'rxjs';
import { catchError } from 'rxjs/operators';

this.http.get('/api/data').pipe(
  // catchError usage here
).subscribe(data => console.log(data));

A catchError(() => { return 'fallback'; })

B catchError(() => of('fallback'))

C catchError(() => 'fallback')

D catchError(() => of(fallback))

💡 Hint

The fallback must be an observable, not a plain value.

catchError expects a function returning an observable. of('fallback') creates an observable emitting the string 'fallback'. Options A and B return plain strings, causing errors. Option B references an undefined variable fallback.

🔧 Debug

advanced

Why does this catchError not handle the error as expected?

Given this code snippet, why does the error still propagate to the subscriber's error handler?

Angular

this.http.get('/api/data').pipe(
  catchError(err => {
    console.error('Error caught:', err);
    throw err;
  })
).subscribe({
  next: data => console.log('Data:', data),
  error: err => console.log('Subscriber error:', err)
});

A Because rethrowing the error inside catchError causes the observable to error again, propagating to subscriber.

B Because catchError must return a Promise to handle errors properly.

C Because catchError only catches synchronous errors, not HTTP errors.

D Because the error is swallowed and never reaches the subscriber.

💡 Hint

What happens if you throw inside a catchError callback?

Throwing an error inside catchError re-emits the error, causing the observable to error again and the subscriber's error handler to be called. To handle the error and prevent propagation, catchError must return a new observable.

❓ state_output

advanced

What is the output sequence when catchError returns a fallback observable?

What will be logged to the console when this code runs?

Angular

import { of, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

of('start').pipe(
  catchError(() => of('fallback'))
).subscribe({
  next: val => console.log('Next:', val),
  error: err => console.log('Error:', err),
  complete: () => console.log('Complete')
});

throwError(() => new Error('fail')).pipe(
  catchError(() => of('fallback'))
).subscribe({
  next: val => console.log('Next:', val),
  error: err => console.log('Error:', err),
  complete: () => console.log('Complete')
});

A

Next: start
Error: fail
Next: fallback
Complete

B

Next: start
Next: fallback
Complete
Complete

C

Next: start
Complete
Next: fallback
Complete

D

Error: fail
Next: fallback
Complete
Complete

💡 Hint

Remember that of emits values and completes, and throwError emits an error.

The first observable emits 'start' and completes normally. The second observable errors, but catchError catches it and returns of('fallback'), which emits 'fallback' and completes. So the logs show 'Next: start', 'Complete', then 'Next: fallback', 'Complete'.

🧠 Conceptual

expert

Why is catchError preferred over try-catch for handling HTTP errors in Angular?

In Angular services using RxJS, why should you use catchError instead of a traditional try-catch block to handle HTTP errors?

A Because HTTP calls are asynchronous and return observables, so errors must be handled in the observable stream using catchError.

B Because try-catch blocks only work with synchronous code and cannot catch errors from observables.

C Because catchError allows you to recover from errors and continue the observable stream, unlike try-catch.

D All of the above.

💡 Hint

Think about how asynchronous code and observables work in Angular.

All statements are true: HTTP calls return observables which are asynchronous. try-catch cannot catch errors inside observables. catchError handles errors inside the observable stream and can recover or replace the stream, making it the correct choice.

Practice

1. What is the main purpose of catchError in Angular's RxJS?

easy

A. To delay the emission of values in an Observable

B. To catch errors in an Observable stream and handle them gracefully

C. To create a new Observable from scratch

D. To unsubscribe from an Observable automatically

Solution

1. Step 1: Understand what catchError does

   catchError is used to catch errors that happen in an Observable stream and lets you handle them without breaking the stream.

2. Step 2: Compare with other options

   Creating new Observables, delaying emissions, or unsubscribing are different RxJS tasks not related to catchError.

3. Final Answer:

   To catch errors in an Observable stream and handle them gracefully -> Option B

4. Quick Check:

   catchError handles errors [OK]

Hint: catchError is for handling errors inside Observable streams [OK]

Common Mistakes:

• Thinking catchError creates Observables
• Confusing catchError with delay or unsubscribe
• Assuming catchError stops the Observable completely

2. Which of the following is the correct syntax to use catchError inside an Observable pipe?

easy

A. catchError(observable, error => of('Error caught'))

B. observable.catchError(error => of('Error caught'))

C. observable.pipe(catchError(error => of('Error caught')))

D. observable.pipe(catchError => error => of('Error caught'))

Solution

1. Step 1: Recall the correct usage of catchError

   catchError is used inside pipe() and takes a function with an error parameter returning a new Observable.

2. Step 2: Identify the correct syntax

   observable.pipe(catchError(error => of('Error caught'))) correctly uses pipe(catchError(error => of('Error caught'))). Other options misuse method chaining or syntax.

3. Final Answer:

   observable.pipe(catchError(error => of('Error caught'))) -> Option C

4. Quick Check:

   Use catchError inside pipe() [OK]

Hint: Always use catchError inside pipe() with a function [OK]

Common Mistakes:

• Calling catchError directly on observable
• Wrong arrow function syntax inside catchError
• Passing catchError arguments incorrectly

3. Given the code below, what will be the output?

import { of, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

const source$ = throwError(() => new Error('Oops!'));

source$.pipe(
  catchError(err => of('Error handled'))
).subscribe(value => console.log(value));

medium

A. Throws an error and stops

B. No output

C. Logs 'Oops!'

D. Logs 'Error handled'

Solution

1. Step 1: Understand throwError and catchError interaction

   throwError creates an Observable that immediately errors. catchError catches this error and returns a new Observable emitting 'Error handled'.

2. Step 2: Trace the subscription output

   The subscriber receives 'Error handled' and logs it. The original error is replaced by the catchError Observable.

3. Final Answer:

   Logs 'Error handled' -> Option D

4. Quick Check:

   catchError replaces error with new value [OK]

Hint: catchError replaces error with new Observable output [OK]

Common Mistakes:

• Expecting original error to be logged
• Thinking error stops the stream without catchError
• Confusing error message with emitted value

4. Identify the error in this code snippet using catchError:

import { of, throwError } from 'rxjs';
import { catchError } from 'rxjs/operators';

const source$ = throwError(() => new Error('Fail'));

source$.pipe(
  catchError(err) {
    return of('Recovered');
  }
).subscribe(console.log);

medium

A. Missing parentheses around catchError argument function

B. Using throwError incorrectly

C. Not subscribing to the Observable

D. Returning a string instead of an Observable inside catchError

Solution

1. Step 1: Check catchError function syntax

   The argument to catchError must be a function expression or arrow function inside parentheses. Here, parentheses are missing around the function.

2. Step 2: Verify other parts

   throwError usage is correct, subscription exists, and return value inside catchError is an Observable (of('Recovered')), so no issues there.

3. Final Answer:

   Missing parentheses around catchError argument function -> Option A

4. Quick Check:

   Function argument to catchError needs parentheses [OK]

Hint: Wrap catchError callback in parentheses or use arrow function [OK]

Common Mistakes:

• Omitting parentheses around function in catchError
• Returning non-Observable values inside catchError
• Not subscribing to see output

5. You want to retry an HTTP request up to 3 times and then handle errors gracefully using catchError. Which code snippet correctly combines retry and catchError?

hard

A. http.get(url).pipe(retry(3), catchError(err => of('Failed after retries')))

B. http.get(url).pipe(catchError(err => of('Failed')), retry(3))

C. http.get(url).pipe(catchError(err => retry(3)), of('Failed'))

D. http.get(url).pipe(retry(3).catchError(err => of('Failed')))

Solution

1. Step 1: Understand operator order in pipe

   retry(3) should come before catchError so retries happen before error handling.

2. Step 2: Analyze each option

   http.get(url).pipe(retry(3), catchError(err => of('Failed after retries'))) correctly chains retry(3) then catchError. http.get(url).pipe(catchError(err => of('Failed')), retry(3)) reverses order, so catchError stops retries. http.get(url).pipe(catchError(err => retry(3)), of('Failed')) misuses catchError and retry. http.get(url).pipe(retry(3).catchError(err => of('Failed'))) uses invalid chaining syntax.

3. Final Answer:

   http.get(url).pipe(retry(3), catchError(err => of('Failed after retries'))) -> Option A

4. Quick Check:

   retry before catchError in pipe [OK]

Hint: Place retry before catchError inside pipe() [OK]

Common Mistakes:

• Putting catchError before retry disables retries
• Using invalid chaining syntax
• Returning non-Observable inside catchError