A Comprehensive Guide to Checking Server Errors from Subscribe in Angular 2

Understanding the RxJS Subscribe Method

In Angular 2, HTTP requests typically return Observable objects, and the core of handling these requests is through the subscribe method. This method accepts three optional callback functions: onNext, onError, and onCompleted. Here, onNext handles each emitted value (e.g., a successful response), onError handles exceptional termination (e.g., server errors), and onCompleted is called when the sequence terminates gracefully, indicating no errors occurred.

Practical Scenario for Handling Server Errors

Consider a form submission scenario: a user creates a project object, but server validation fails, returning a 400 error. We need to capture these errors and display them on the form, while routing to a new page if no errors occur. The initial code might look like this, but it contains a logical error because if (!this.errors) executes outside the subscribe block and cannot correctly reflect asynchronous results.

this.projectService.create(project)
    .subscribe(
        result => console.log(result),
        error => {
            this.errors = error
        }
    );
}

if (!this.errors) {
    // route to new page
}

The issue is that subscribe is asynchronous, so the check for this.errors might execute before the error is set. The correct approach is to move the routing logic into the onCompleted callback, as it only triggers when there are no errors.

Improved Code Example

Here is the corrected code using the onCompleted callback to handle routing in the absence of errors:

this.httpService.makeRequest()
    .subscribe(
      result => {
        // Handle successful result
        console.log(result)
      },
      error => {
        this.errors = error; // Capture and store the error
      },
      () => {
        // 'onCompleted' callback: no errors, route to new page
        if (!this.errors) {
          // Execute routing logic
        }
      }
    );

In this example, onCompleted ensures that the error status is checked after the request fully completes, avoiding race conditions. If the server returns an error, onError sets this.errors, and onCompleted does not execute; conversely, if the request succeeds, onCompleted triggers and allows routing.

Using the finally Operator for Additional Processing

Beyond the basic callbacks, RxJS provides the finally operator, which is called when the Observable sequence terminates, regardless of success or failure. This is useful for executing logic that must always occur, such as logging or UI cleanup. First, import the necessary modules:

import { Observable } from 'rxjs/Rx';
import 'rxjs/add/operator/finally';

Then, use it in the code:

this.httpService.getRequest()
    .finally(() => {
      // Execute after termination, e.g., handle logging
      console.log('Request completed, handling logging logic...');
    })
    .subscribe (
      result => {
        // Handle result
        console.log(result)
      },
      error => {
        this.errors = error;
      },
      () => {
        // No errors, route to new page
      }
    );

The finally operator ensures that certain operations (e.g., hiding a loading indicator) always execute, improving code robustness. Note that it does not affect the execution order of error or success logic.

Summary and Best Practices

In Angular 2, by appropriately using the callback parameters of subscribe, you can efficiently handle HTTP request errors and successes. Key points include: using onError to capture server errors, onCompleted to handle no-error logic, and finally for resource cleanup. Avoid relying on asynchronous variables outside subscribe to prevent timing issues. This approach is not only applicable to form submissions but can be extended to other HTTP interactions, enhancing application maintainability and user experience.