Global exception filters in NestJS - Performance & Optimization

Performance: Global exception filters

MEDIUM IMPACT

Global exception filters affect the response time and error handling flow, impacting interaction responsiveness and server response speed.

Handling all exceptions globally in a NestJS application

NestJS

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

@Catch()
export class GlobalFilter implements ExceptionFilter {
  async catch(exception: any, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();
    const status = exception.status || 500;
    // Use async non-blocking logging
    await asyncLogging(exception);
    response.status(status).json({ message: 'Error occurred' });
  }
}

Using asynchronous non-blocking operations avoids delaying the response, improving interaction responsiveness.

📈 Performance GainReduces blocking time to near 0ms, improving INP significantly.

Handling all exceptions 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 or blocking operation here
    heavySyncLogging(exception);
    response.status(status).json({ message: 'Error occurred' });
  }
}

Blocking synchronous operations inside the filter delay response sending, increasing interaction latency.

📉 Performance CostBlocks response for 50-200ms depending on logging complexity, increasing INP.

Performance Comparison

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

Rendering Pipeline

Global exception filters intercept errors during request handling before the response is sent. They affect the server response phase, which impacts how quickly the browser receives the final content.

→Request Handling

→Response Generation

⚠️ BottleneckBlocking synchronous operations inside the filter delay response generation.

Core Web Vital Affected

INP

Global exception filters affect the response time and error handling flow, impacting interaction responsiveness and server response speed.

Optimization Tips

1Avoid synchronous blocking code inside global exception filters.

2Use asynchronous logging or error reporting to keep response fast.

3Test error response times in Network tab to detect slow filters.

Performance Quiz - 3 Questions

What is the main performance risk of using synchronous operations inside a global exception filter in NestJS?

A It blocks the response, increasing interaction latency.

B It increases DOM nodes on the client.

C It causes layout shifts in the browser.

D It reduces bundle size.

DevTools: Network

How to check: Open DevTools, go to Network tab, trigger an error response, and check the response time for error requests.

What to look for: Look for long response times on error requests indicating blocking operations in exception filters.

Practice

1. What is the main purpose of a global exception filter in a NestJS application?

easy

A. To catch and handle exceptions across the entire application in one place

B. To define routes for the application

C. To manage database connections

D. To serve static files

Solution

1. Step 1: Understand the role of exception filters

   Exception filters in NestJS are designed to catch errors and exceptions that occur during request processing.

2. Step 2: Identify the scope of global exception filters

   Global exception filters apply this error handling across the entire app, centralizing error management.

3. Final Answer:

   To catch and handle exceptions across the entire application in one place -> Option A

4. Quick Check:

   Global exception filters = app-wide error handling [OK]

Hint: Global filters catch errors everywhere in the app [OK]

Common Mistakes:

• Confusing filters with routing or database management
• Thinking filters serve static files
• Assuming filters only handle specific routes

2. Which of the following is the correct way to apply a global exception filter in the main.ts file of a NestJS app?

easy

A. app.useGlobalFilters(new MyExceptionFilter())

B. app.setGlobalFilters(new MyExceptionFilter())

C. app.applyGlobalFilters(MyExceptionFilter)

D. app.registerGlobalFilter(MyExceptionFilter)

Solution

1. Step 1: Recall the NestJS method for global filters

   The official method to apply global exception filters is useGlobalFilters() on the app instance.

2. Step 2: Check the syntax for passing the filter

   The filter must be instantiated with new before passing it to useGlobalFilters().

3. Final Answer:

   app.useGlobalFilters(new MyExceptionFilter()) -> Option A

4. Quick Check:

   Global filter method = useGlobalFilters() [OK]

Hint: Use app.useGlobalFilters(new Filter()) in main.ts [OK]

Common Mistakes:

• Using incorrect method names like setGlobalFilters
• Passing class without instantiation
• Confusing with middleware registration methods

3. Given this global exception filter code snippet, what will be the HTTP status code returned when an exception is thrown?

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

@Catch()
export class AllExceptionsFilter implements ExceptionFilter {
  catch(exception: unknown, host: ArgumentsHost) {
    const ctx = host.switchToHttp();
    const response = ctx.getResponse();

    if (exception instanceof HttpException) {
      const status = exception.getStatus();
      response.status(status).json({ message: exception.message });
    } else {
      response.status(500).json({ message: 'Internal server error' });
    }
  }
}

medium

A. 200

B. 500

C. Depends on the exception type

D. 404

Solution

1. Step 1: Analyze the filter's catch method

   The filter checks if the exception is an instance of HttpException and uses its status code.

2. Step 2: Determine status code for other exceptions

   If not an HttpException, it returns status 500 with a generic error message.

3. Final Answer:

   Depends on the exception type -> Option C

4. Quick Check:

   HttpException status or 500 for others [OK]

Hint: Check if exception is HttpException for status code [OK]

Common Mistakes:

• Assuming always 500 status
• Ignoring HttpException status extraction
• Confusing 404 with 500 errors

4. Identify the error in this global exception filter implementation:

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

@Catch()
export class MyFilter implements ExceptionFilter {
  catch(exception: any, host: ArgumentsHost) {
    const response = host.getResponse();
    response.status(400).json({ error: 'Bad Request' });
  }
}

medium

A. Missing @Injectable() decorator on the filter class

B. The @Catch() decorator must specify exception types

C. The catch method must return a value

D. host.getResponse() is incorrect; should use host.switchToHttp().getResponse()

Solution

1. Step 1: Check how to get response object

   In NestJS, to get the HTTP response, use host.switchToHttp().getResponse(), not host.getResponse().

2. Step 2: Verify other parts

   The @Catch() decorator can be empty to catch all exceptions, and the catch method does not need to return a value. @Injectable() is not required for filters.

3. Final Answer:

   host.getResponse() is incorrect; should use host.switchToHttp().getResponse() -> Option D

4. Quick Check:

   Use switchToHttp() to access response [OK]

Hint: Use host.switchToHttp().getResponse() to get response [OK]

Common Mistakes:

• Calling host.getResponse() directly
• Thinking @Injectable() is mandatory for filters
• Expecting catch to return a value

5. You want to create a global exception filter that logs all exceptions and returns a JSON response with a custom message and status code 418 (I'm a teapot) for all errors except HttpExceptions, which should keep their original status. How should you implement the catch method?

hard

A. Always respond with status 418 and ignore HttpException status

B. Check if exception is HttpException, use its status; else log and respond with 418 and custom message

C. Only log exceptions but do not modify the response

D. Throw the exception again to let NestJS handle it

Solution

1. Step 1: Handle HttpException separately

   Check if the exception is an instance of HttpException to preserve its status and message.

2. Step 2: For other exceptions, log and respond with status 418

   Log the error details, then send a JSON response with status 418 and a custom message.

3. Final Answer:

   Check if exception is HttpException, use its status; else log and respond with 418 and custom message -> Option B

4. Quick Check:

   Preserve HttpException status, else respond 418 with log [OK]

Hint: Preserve HttpException status; else respond 418 with log [OK]

Common Mistakes:

• Ignoring HttpException status and always sending 418
• Not logging exceptions
• Re-throwing exceptions instead of handling