Built-in HTTP exceptions in NestJS - Step-by-Step Execution

Concept Flow - Built-in HTTP exceptions

Request received

↓

Controller method runs

↓

Check for error condition

Yes↓

Throw built-in HTTP exception

↓

NestJS catches exception

↓

Send HTTP error response

↓

Client receives error status and message

When an error condition occurs in a controller, NestJS built-in HTTP exceptions are thrown, caught by the framework, and converted into proper HTTP error responses sent back to the client.

Execution Sample

NestJS

import { Controller, Get, Param, NotFoundException } from '@nestjs/common';

@Controller('items')
export class ItemsController {
  @Get(':id')
  getItem(@Param('id') id: string) {
    throw new NotFoundException('Item not found');
  }
}

This code throws a 404 Not Found HTTP exception when the getItem method is called.

Execution Table

Step	Action	Exception Thrown?	Exception Type	Response Sent
1	Request to GET /items/:id received	No	N/A	N/A
2	Controller method getItem() executes	Yes	NotFoundException	No
3	NestJS catches NotFoundException	Yes	NotFoundException	No
4	NestJS sends HTTP 404 response with message 'Item not found'	Yes	NotFoundException	HTTP 404 Not Found with message
5	Client receives HTTP 404 response	No	N/A	HTTP 404 Not Found with message

💡 Exception thrown in controller, caught by NestJS, HTTP 404 response sent to client

Variable Tracker

Variable	Start	After Step 2	After Step 4	Final
exception	undefined	NotFoundException instance with message 'Item not found'	Handled by NestJS	Response sent to client

Key Moments - 2 Insights

Why does the controller method throw an exception instead of returning a response?

Throwing a built-in HTTP exception immediately stops the method and signals NestJS to handle the error and send the correct HTTP response, as shown in execution_table step 2 and 3.

What happens if no exception is thrown in the controller?

If no exception is thrown, NestJS sends the normal successful response. The execution_table shows no exception thrown in step 1 and 5, meaning normal flow continues.

Visual Quiz - 3 Questions

Look at the execution table, at which step does NestJS catch the exception?

A Step 4

B Step 3

C Step 2

D Step 5

💡 Hint

Check the 'Exception Thrown?' and 'Exception Type' columns in the execution_table at step 3

According to the variable tracker, what is the state of the 'exception' variable after step 4?

A Handled by NestJS

B NotFoundException instance

C Undefined

D Response sent to client

💡 Hint

Look at the 'exception' row and the 'After Step 4' column in variable_tracker

If the controller did not throw an exception, what would the execution table show at step 2?

A Exception Thrown? = Yes

B Response Sent = HTTP 404

C Exception Thrown? = No

D Exception Type = NotFoundException

💡 Hint

Refer to the 'Exception Thrown?' column in execution_table step 1 and 5 for normal flow

Concept Snapshot

Built-in HTTP exceptions in NestJS are classes like NotFoundException.
Throw them in controllers to signal errors.
NestJS catches these exceptions automatically.
It sends the proper HTTP status and message to clients.
Use exceptions to simplify error handling in your app.

Full Transcript

In NestJS, when a controller detects an error, it throws a built-in HTTP exception like NotFoundException. This stops the controller method immediately. NestJS framework catches this exception and converts it into an HTTP response with the correct status code and message. For example, throwing NotFoundException sends a 404 status with a message. This flow helps developers handle errors cleanly without manually crafting responses. The execution table shows each step: request received, exception thrown, NestJS catching it, sending response, and client receiving it. The variable tracker shows the exception variable state changes. Key moments clarify why throwing exceptions is preferred and what happens if no exception is thrown. The visual quiz tests understanding of when exceptions are caught and how variables change. This method makes error handling in NestJS simple and consistent.

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