Exception filters in NestJS - Performance & Optimization

Performance: Exception filters

MEDIUM IMPACT

Exception filters affect the server response time and error handling flow, impacting how quickly errors are processed and sent to the client.

Handling errors globally in a NestJS application

NestJS

import { Catch, ExceptionFilter, ArgumentsHost, Logger } from '@nestjs/common';

@Catch()
export class GlobalFilter implements ExceptionFilter {
  private readonly logger = new Logger(GlobalFilter.name);

  catch(exception: any, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    const status = exception.status || 500;
    // Asynchronous logging without blocking
    setImmediate(() => this.logger.error(exception.message));
    response.status(status).json({ message: exception.message });
  }
}

Moves heavy logging off the main thread to avoid blocking response sending.

📈 Performance GainResponse sent immediately, logging runs asynchronously, reducing latency by ~50-100ms

Handling errors globally in a NestJS application

NestJS

import { Catch, ExceptionFilter, ArgumentsHost } from '@nestjs/common';

@Catch()
export class GlobalFilter implements ExceptionFilter {
  catch(exception: any, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    const status = exception.status || 500;
    // Synchronous heavy logging
    for (let i = 0; i < 1000000; i++) { /* heavy loop */ }
    response.status(status).json({ message: exception.message });
  }
}

Heavy synchronous operations block the event loop delaying response and increasing latency.

📉 Performance CostBlocks response for 50-100ms depending on operation complexity

Performance Comparison

Pattern	DOM Operations	Reflows	Paint Cost	Verdict
Synchronous heavy processing in filter	0 (server-side)	0 (server-side)	0 (server-side)	[X] Bad
Asynchronous logging in filter	0 (server-side)	0 (server-side)	0 (server-side)	[OK] Good

Rendering Pipeline

Exception filters intercept errors during request processing and prepare the HTTP response. They affect the server's response time but do not directly impact browser rendering.

→Server Processing

→Response Preparation

⚠️ BottleneckSynchronous heavy operations inside filters block the event loop delaying response.

Optimization Tips

1Avoid heavy synchronous operations inside exception filters to prevent blocking the event loop.

2Use asynchronous or deferred logging to keep error handling fast.

3Exception filters impact server response time but do not directly affect browser rendering metrics.

Performance Quiz - 3 Questions

What is the main performance risk of doing heavy synchronous work inside a NestJS exception filter?

A It causes layout shifts on the client side.

B It blocks the event loop delaying the HTTP response.

C It increases the browser's paint time.

D It reduces the bundle size.

DevTools: Network and Performance panels

How to check: Open DevTools, go to Network tab, trigger an error response, check response time. Use Performance tab to record and analyze server response delays.

What to look for: Look for long server response times and blocking tasks delaying the response in the flame chart.

Practice

1. What is the main purpose of an exception filter in NestJS?

easy

A. To catch and handle errors in a centralized way

B. To create database connections automatically

C. To define routes for HTTP requests

D. To manage user authentication

Solution

1. Step 1: Understand what exception filters do

   Exception filters catch errors thrown during request handling and allow custom responses.

2. Step 2: Compare with other options

   Options B, C, and D relate to other NestJS features, not error handling.

3. Final Answer:

   To catch and handle errors in a centralized way -> Option A

4. Quick Check:

   Exception filters = centralized error handling [OK]

Hint: Exception filters handle errors centrally, not routes or auth [OK]

Common Mistakes:

• Confusing exception filters with middleware
• Thinking filters manage routes or database
• Assuming filters handle authentication

2. Which decorator is used to define an exception filter class in NestJS?

easy

A. @Exception()

B. @Catch()

C. @Filter()

D. @ErrorHandler()

Solution

1. Step 1: Recall the decorator for exception filters

   The correct decorator to mark a class as an exception filter is @Catch().

2. Step 2: Verify other decorators

   @Exception(), @Filter(), and @ErrorHandler() are not valid NestJS decorators for filters.

3. Final Answer:

   @Catch() -> Option B

4. Quick Check:

   @Catch() marks exception filters [OK]

Hint: Remember: @Catch() catches exceptions in filters [OK]

Common Mistakes:

• Using @Exception() instead of @Catch()
• Confusing with @Filter() which is not a decorator
• Assuming @ErrorHandler() exists in NestJS

3. Given this filter code, what will be the HTTP status code sent when a NotFoundException is thrown?

import { ExceptionFilter, Catch, ArgumentsHost, NotFoundException } from '@nestjs/common';

@Catch(NotFoundException)
export class NotFoundFilter implements ExceptionFilter {
  catch(exception: NotFoundException, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    response.status(404).json({ message: 'Resource not found' });
  }
}

medium

A. 404

B. 200

C. 500

D. 400

Solution

1. Step 1: Analyze the response status set in the filter

   The filter explicitly sets the status code to 404 using response.status(404).

2. Step 2: Understand the exception type caught

   The filter catches NotFoundException, which corresponds to HTTP 404 errors.

3. Final Answer:

   404 -> Option A

4. Quick Check:

   NotFoundException triggers 404 status [OK]

Hint: Check response.status() call inside catch method [OK]

Common Mistakes:

• Assuming default 500 status without custom filter
• Confusing 404 with 400 or 200
• Ignoring the status set in the filter

4. Identify the error in this exception filter code:

import { ExceptionFilter, Catch, ArgumentsHost } from '@nestjs/common';

@Catch(HttpException)
export class AllExceptionsFilter implements ExceptionFilter {
  catch(exception, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    response.status(500).json({ message: exception.message });
  }
}

medium

A. Missing exception type in @Catch() decorator

B. catch method missing return type

C. Using exception.message instead of exception.getMessage()

D. Not importing HttpException class

Solution

1. Step 1: Check the @Catch() decorator usage

   The @Catch(HttpException) references HttpException, but it is not imported from '@nestjs/common'.

2. Step 2: Validate other parts

   catch method can omit return type and exception type in loose TS, exception.message is valid.

3. Final Answer:

   Not importing HttpException class -> Option D

4. Quick Check:

   Import HttpException for @Catch(HttpException) [OK]

Hint: Import exception classes used in @Catch() [OK]

Common Mistakes:

• Not importing referenced exception types like HttpException
• Assuming catch method needs strict return type
• Thinking exception needs getMessage() method

5. You want to create a global exception filter that catches all exceptions and logs the error before sending a generic message. Which of these is the correct way to apply it globally in NestJS?

hard

A. Register the filter in a module's providers array only

B. Add @Global() decorator to the filter class

C. Use app.useGlobalFilters(new YourFilter()) in main.ts after creating the filter class

D. Call app.setGlobalExceptionFilter(YourFilter) in main.ts

Solution

1. Step 1: Recall how to apply global filters in NestJS

   Global filters are applied using app.useGlobalFilters() method in the main bootstrap file.

2. Step 2: Evaluate other options

   @Global() is for modules, not filters; registering in providers is local; app.setGlobalExceptionFilter() does not exist.

3. Final Answer:

   Use app.useGlobalFilters(new YourFilter()) in main.ts after creating the filter class -> Option C

4. Quick Check:

   Global filters use app.useGlobalFilters() [OK]

Hint: Global filters need app.useGlobalFilters() call [OK]

Common Mistakes:

• Using @Global() decorator on filter class
• Registering filter only in providers without global call
• Assuming app.setGlobalExceptionFilter() exists