NestJS: stop handling errors like this!

I see people making this mistake all the time.

Let's say you've got an API server written in NestJS, and you need an endpoint for fetching a single product by its ID. So, in your product.service.ts you would typically write:

async findOne(id: number) {
  try {
    return await this.productRepository.findOneOrFail(id);
  } catch (err) {
    throw new NotFoundException();
  }
}

(I'm using TypeORM here, but the same principle can be applied to other libraries as well.)

So what we've got here? You attempt to query a product by its ID, and if there is no product with this ID, you just throw the 404. And in your product.controller.ts you simply write:

@Get(':id')
findOne(@Param('id') id: string) {
  return this.productService.findOne(+id);
}

And everything indeed works fine.

So what's the problem with this?

The thing is that the above code would work well for REST APIs. But what if tomorrow you will need to fetch that product via GraphQL or WebSockets? The NotFoundException() and its fellow HTTP-related exceptions will not be suitable for that any more. You will definitely need different error handling.

Therefore, by throwing HTTP-related errors (exceptions) from services you simply make your code less reusable.

What to do instead?

As we have implicitly mentioned above, the HTTP-related exceptions are suited only for REST APIs. But so are controllers!

You see, NestJS controllers are used only during REST API development, while services can have wider use. This makes controllers the perfect place for throwing HTTP-related exceptions.

Thus, in the simplest scenario, your product.service.ts code (fragment) would look just like this:

findOne(id: number) {
  return this.productRepository.findOneOrFail(id);
}

And in the product.controller.ts you now handle the "not found" error:

@Get(':id')
async findOne(@Param('id') id: string) {
  try {
    return await this.productService.findOne(+id);
  } catch (err) {
    throw new NotFoundException();
  }
}

Of course, if you need more sophisticated error handling, you can define custom error classes to throw from services and handle in controllers (for REST) or resolvers (for GraphQL).

Conclusion

Don't throw HTTP-related exceptions from services, throw them from controllers!

Have you been making this mistake before reading this article? Comment down below!

And, of course, leave your reaction to this article, share it with your friends via social media and follow me on this platform!

Don't stop coding,
don't stop growing,
stand with Ukraine! 🇺🇦