Category: NestJS

A quick post to note two important things when it comes to Node.js and Observables.

Unhandled exceptions kill the server

One of the paramount aspect of webservices on Node.js to remember is: any unhandled exceptions will blow up the webserver. It won’t just return ‘500’ to the user. It will, but also blow up the webserver.

This leads to 2 important things to consider:

• a webservice on Node.JS must be monitored by a Process Manager, and automatically relaunched when failing. This, of course, is ok with your service, but you designed it to fail-fast, in accordance to the 12-factor principles.
• you should handle as many errors as possible and do appropriate actions (logging, error-management notifying, replacement-value providing, etc.), so that only unforeseen exceptions will actually blow up the server. Which is actually part of Node.js philosophy: let unhandled exceptions kill the server, because if such exceptions occured, the server might be in a unstable state now; so better kill and respawn it.

Observables’ subscribe: the nuclear time-bomb in your code

It’s easy to deal with a received Observable and only care about the positive outcomes and “leaving for later” the handling of possible but “unlikely” errors the Observable might crash on.

obs.subscribe( result => { ... } );

If you wrote above code, you’re a punk, or you’re just unaware of the nuclear mole you just set up. You heard somewhere, especially in Node.js event-based programming: “always handle errors” but you didn’t handle possible errors in the subscribe. Mayyybe you got to the impression you were safe thanks to some larger-scope error-handling in your code (of course, you’re not a fool, you didn’t surround above subscribe with try… catch… knowing that the subscription itself can not fail), in such manner:

import { Observable, throwError } from "rxjs";

/**
 * Returns a Promise which returns a result,
 * only if this one matches some conditions.
 * NOTE: tons of ways to do that better, this is
 * only for the example
 */
async function showMustGoOn(): Promise<any> {
  return new Promise((resolve, reject) => {
    const obs: Observable<any> = throwError("You'll never get me if not in the subscribe error handler!");
    obs.subscribe(
      (result) => {
        if (result.type === 5) { // some conditions...
          resolve(result);
        }
      }
    );
  });
}

/**
 * A function that could give the illusion that any error
 * here or deeper will be caught and handled.
 */
async function supposedlyErrorShieldingFunction() {
  // Bring it on, synchronous errors!
  // It really does not make sense to do this here, because
  // showMustGoOn is asynchronous (and we don't use 'await')
  // and .then and .catch can't fail (their asynchronous callbacks can)
  try {
    const result: Promise<any> = showMustGoOn();
    result.then(
      (value) => { /*...*/ },
      (err) => { /* I'll catch you here if that's what it takes! */ }
    ).catch(
      (err) => { /* Otherwise, I'm totally cornering you here! */ }
    );
  } catch (e) {
    /* There's basically no way you escape me now. As true as I'm a punk. */
  }
}

supposedlyErrorShieldingFunction();

In above code, you’re trying to catch any error that bubbles up in the synchronous flow and within the returned Promise, but this does not address the rule: “handle all exceptions, especially in Observables and Promises” because the asynchronous error happening within the Observable is not handled. This error will bubble up unattended to the root of the process and make it crash.

It’s not a recommended way, but for the purpose of experiment, you could add this block of code anywhere:

// This catches all uncaught exception in the application
process.on('uncaughtException', error => {
  console.log('uncaughtException', error);
});

/* // This would catch all unattended Promise rejection
process.on('unhandledRejection', (error: any) => {
  console.log('unhandledRejection', error.message);
});
 */

which would print:

uncaughtException You'll never get me if not in the subscribe handler!

Those global catchers are not recommended, especially in production, because of above-mentionned philosophy: let unhandled exceptions kill the server, because if such exceptions occured, the server might be in a unstable state now; so better kill and respawn it.

This is more a memo concrete example of how Promises work when it comes to error-handling. It also explains some of NestJS Controller behaviour when it comes to occuring errors.

Below code and comments are self-explanatory.

@Controller('myRoute')
 export class AlarmController {
   @Get()
   public aNestControllerEndPoint() {
      // this snippet could be in any block of code,
      // but some of below comments tells about
      // Nest http response in different cases.
      try {
        return myAsyncFunc()
          .then(
            onfulfilled => {
              // We enter here if myAsyncFunc returns a resolved Promise
              // Any exception happening in this block will be caught in the
              // .catch block below.
              console.log('success!', onfulfilled);
              return onfulfilled;
            },
            onrejected => {
              console.error("3 - Request fails with error", onrejected);
              // We enter here if :
              // - myAsyncFunc returns a rejected Promise
              // - an unhandled exception occurs in myAsyncFunc
              // We have to return a Promise: here, we return an auto-rejected Promise
              // which will be caught in the .catch block below.
              // Also in this particular path, we decide to generate an exception
              // of a particular kind.
              return Promise.reject( new ConflictException() );
              // or simply:
              // throw new ConflictException();
            }
          )
          .catch(
            (reason: any) => {
              // We enter here:
              // - if an exception occured in the 'onfulfilled' or 'onrejected' block above
              // - if the 'onfulfilled' or 'onrejected' block above returned a rejected Promise
              // - if an exception occured in myAsyncFunc and no 'onrejected' block
              //   like above exists
              // - if myAsyncFunc returns a rejected Promise and no 'onrejected' block
              //   like above exists
              console.error("2 - Request fails with error", reason);
              throw reason;
              // or:
              //  return Promise.reject( reason );
            }
          );
      } catch (e) {
        // Because we used 'await', we'll enter this block if:
        // - an exception occurs in myAsyncFunc and is not handled
        //   above by 'onrejected' or .catch above
        // - myAsyncFunc returns a rejected Promise which is not handled
        //   above by 'onrejected' or .catch above
        // - an exception occurs in above blocks ('onfulfilled', 'onrejected' or .catch)
        //   and is not handled by subsequent blocks
        // - above blocks ('onfulfilled', 'onrejected' or .catch) returns a rejected Promise
        //   not handled by subsequent blocks
        // If we hadn't used 'await', the server would instanly replied '200',
        // and meanwhile the async process would be on-going.
        console.error("1 - Request fails with error: ", e);
        // Letting an unhandled exception go will cause one of two things:
        // - NestJS interceptor will catch it, and if it's recognised HttpException,
        //   it will generate an appropriate HTTP answer (with appropriate HTTP code)
        //   example with: throw new HttpException('error message', 400); // import { HttpException } from '@nestjs/common';
        //   example with: throw new ServiceUnavailableException(); // import { ServiceUnavailableException } from '@nestjs/common';
        // - or an error 500 will be generate, and due to the nature of Nodejs
        //   regarding unhandled exceptions, we server will crash (and has to be
        //   braught back up by an Process Manager such as PM2, docker-composer, etc.)
        //   example with: throw new Error("Unrecognised exception");
        throw e;
        // WARNING: if we don't re-throw an exception here and returns nothing,
        // NestJS will generate a 20x response with '' as body.
      }
    }
 }