Built-in HTTP exceptions in NestJS - Performance & Optimization

Performance: Built-in HTTP exceptions

MEDIUM IMPACT

This affects server response time and client perceived latency by how quickly errors are handled and sent back.

Handling HTTP errors in a NestJS controller

NestJS

throw new NotFoundException('User not found');

Built-in exceptions immediately generate proper HTTP responses without extra processing.

📈 Performance Gainreduces response time by avoiding error conversion overhead

Handling HTTP errors in a NestJS controller

NestJS

throw new Error('User not found');

Generic errors cause NestJS to do extra work to convert them into HTTP responses, adding delay.

📉 Performance Costblocks response for extra milliseconds due to error transformation

Performance Comparison

Pattern	Server Processing	Error Handling Overhead	Response Time	Verdict
Generic Error Throw	Normal	High (extra conversion)	Slower	[X] Bad
Built-in HTTP Exception	Normal	Low (direct response)	Faster	[OK] Good

Rendering Pipeline

When a built-in HTTP exception is thrown, NestJS quickly creates an HTTP response with the correct status and message, skipping extra error handling steps.

→Server Processing

→Response Generation

⚠️ BottleneckError transformation and response formatting

Core Web Vital Affected

LCP

This affects server response time and client perceived latency by how quickly errors are handled and sent back.

Optimization Tips

1Always use NestJS built-in HTTP exceptions for error handling to speed up response time.

2Avoid throwing generic errors that require extra server processing to convert.

3Faster error responses improve Largest Contentful Paint (LCP) and user experience.

Performance Quiz - 3 Questions

Why are built-in HTTP exceptions in NestJS better for performance than generic errors?

A They delay response to batch errors together.

B They add more logging which speeds up debugging.

C They directly create HTTP responses without extra error conversion.

D They reduce server CPU usage by skipping validation.

DevTools: Network

How to check: Open DevTools, go to Network tab, trigger the error endpoint, and inspect the response time and status code.

What to look for: Look for faster response times and correct HTTP status codes when using built-in exceptions.

Practice

1. What is the purpose of using built-in HTTP exceptions like NotFoundException in a NestJS controller?

easy

A. To automatically log all requests to the server

B. To create new API routes dynamically

C. To improve database query performance

D. To send a clear HTTP error response with the correct status code and message

Solution

1. Step 1: Understand the role of HTTP exceptions in NestJS

   Built-in HTTP exceptions are used to send error responses with specific HTTP status codes and messages.

2. Step 2: Identify the purpose of NotFoundException

   This exception sends a 404 status code with a message indicating the resource was not found.

3. Final Answer:

   To send a clear HTTP error response with the correct status code and message -> Option D

4. Quick Check:

   HTTP exceptions = clear error responses [OK]

Hint: Exceptions send proper HTTP status codes and messages [OK]

Common Mistakes:

• Thinking exceptions log requests automatically
• Confusing exceptions with database operations
• Assuming exceptions create routes

2. Which of the following is the correct way to throw a BadRequestException in a NestJS controller method?

easy

A. throw new BadRequestException('Invalid input');

B. return BadRequestException('Invalid input');

C. throw BadRequestException('Invalid input');

D. BadRequestException.throw('Invalid input');

Solution

1. Step 1: Recall the syntax for throwing exceptions in NestJS

   Exceptions are thrown using the JavaScript throw new ExceptionClass() syntax.

2. Step 2: Check the correct usage for BadRequestException

   The correct syntax is throw new BadRequestException('message').

3. Final Answer:

   throw new BadRequestException('Invalid input'); -> Option A

4. Quick Check:

   Throw exceptions with throw new [OK]

Hint: Use 'throw new ExceptionName()' to raise exceptions [OK]

Common Mistakes:

• Omitting 'new' keyword when throwing exceptions
• Using return instead of throw
• Calling exception as a function without 'new'

3. Given this NestJS controller method, what HTTP status code will the client receive?

async getUser(id: string) {
  if (!id) {
    throw new BadRequestException('ID is required');
  }
  const user = await this.userService.findById(id);
  if (!user) {
    throw new NotFoundException('User not found');
  }
  return user;
}

medium

A. 200 if user found, 400 if ID missing, 404 if user not found

B. 200 always

C. 500 if user not found

D. 400 if user not found

Solution

1. Step 1: Analyze the conditions for exceptions

   If id is missing, it throws BadRequestException (HTTP 400). If user is not found, it throws NotFoundException (HTTP 404).

2. Step 2: Understand the normal return

   If no exceptions are thrown, the method returns the user with HTTP 200 status.

3. Final Answer:

   200 if user found, 400 if ID missing, 404 if user not found -> Option A

4. Quick Check:

   Exceptions map to HTTP codes 400 and 404, else 200 [OK]

Hint: Check exception types to know HTTP status codes sent [OK]

Common Mistakes:

• Assuming 500 error instead of 404 for not found
• Ignoring the BadRequestException case
• Thinking exceptions return 200 status

4. Identify the error in this NestJS controller snippet that tries to throw a ForbiddenException:

if (!user.isAdmin) {
  ForbiddenException('Access denied');
}

medium

A. Exception class name is incorrect

B. Missing 'throw' keyword before the exception

C. Exception message should be an object, not a string

D. ForbiddenException cannot be used in controllers

Solution

1. Step 1: Check how exceptions are thrown in NestJS

   Exceptions must be thrown using the throw keyword followed by new ExceptionClass().

2. Step 2: Identify the missing part in the code

   The code calls ForbiddenException('Access denied') without throw and new, so it does nothing.

3. Final Answer:

   Missing 'throw' keyword before the exception -> Option B

4. Quick Check:

   Always use 'throw new Exception()' to raise errors [OK]

Hint: Always use 'throw new' to raise exceptions [OK]

Common Mistakes:

• Calling exception as a function without throw
• Forgetting the 'new' keyword
• Using wrong exception class names

5. You want to create a custom error response with status 403 and a detailed message using NestJS built-in exceptions. Which approach correctly extends ForbiddenException to add a custom error code in the response body?

hard

A. class CustomForbiddenException extends ForbiddenException {
constructor() {
super('Access denied');
this.errorCode = 123;
}
}

B. throw new ForbiddenException('Access denied', 123);

C. class CustomForbiddenException extends ForbiddenException {
constructor() {
super({ message: 'Access denied', errorCode: 123 });
}
}

D. throw new ForbiddenException({ message: 'Access denied' }, 123);

Solution

1. Step 1: Understand how to customize exception response body

   Passing an object to super() in the exception constructor customizes the JSON response.

2. Step 2: Check which option correctly extends ForbiddenException

   class CustomForbiddenException extends ForbiddenException { constructor() { super({ message: 'Access denied', errorCode: 123 }); } } passes an object with message and errorCode to super(), correctly customizing the response.

3. Step 3: Identify why other options are incorrect

   throw new ForbiddenException('Access denied', 123); incorrectly passes a second argument as number; class CustomForbiddenException extends ForbiddenException { constructor() { super('Access denied'); this.errorCode = 123; } } sets a property but does not affect response body; throw new ForbiddenException({ message: 'Access denied' }, 123); passes wrong parameters.

4. Final Answer:

   class CustomForbiddenException extends ForbiddenException { constructor() { super({ message: 'Access denied', errorCode: 123 }); } } -> Option C

5. Quick Check:

   Pass object to super() to customize exception response [OK]

Hint: Pass an object with details to super() in custom exception [OK]

Common Mistakes:

• Passing multiple arguments instead of one object
• Setting properties without calling super() properly
• Misunderstanding how to customize exception response