Discover how custom exceptions can save you hours of debugging and make your API shine!
Why Custom exception classes in NestJS? - Purpose & Use Cases
Imagine building a NestJS app where you handle errors by throwing generic exceptions everywhere.
You want to show specific error messages for different problems, but all errors look the same.
Using only generic exceptions makes it hard to tell what went wrong.
You end up writing repetitive code to check error messages and status codes manually.
This slows development and causes bugs when errors are not handled properly.
Custom exception classes let you define clear, reusable error types with their own messages and HTTP status codes.
They make your error handling clean, consistent, and easy to maintain.
throw new HttpException('Bad request', 400);
throw new BadRequestException('Invalid user input');Custom exceptions enable precise error handling and better communication with API clients.
When a user submits a form with wrong data, a BadRequestException clearly tells the client what went wrong, improving user experience.
Generic exceptions make error handling confusing and repetitive.
Custom exception classes provide clear, reusable error types.
This leads to cleaner code and better API responses.
Practice
Solution
Step 1: Understand the role of custom exceptions
Custom exceptions in NestJS help you send clear, specific error messages with HTTP status codes.Step 2: Compare with other options
Options B, C, and D describe unrelated features not handled by custom exceptions.Final Answer:
To define specific error messages and HTTP status codes for your app -> Option DQuick Check:
Custom exceptions = specific messages + status [OK]
- Thinking custom exceptions replace JavaScript Error globally
- Assuming they log errors automatically
- Confusing exceptions with HTTP methods
Solution
Step 1: Check syntax for custom exception
In NestJS, custom exceptions extend HttpException and call super with message and status.Step 2: Validate options
class MyException extends HttpException { constructor() { super('Error', 400); } } correctly extends HttpException and calls super with message and status code. Others do not follow NestJS pattern.Final Answer:
class MyException extends HttpException { constructor() { super('Error', 400); } } -> Option BQuick Check:
Extend HttpException + super(message, status) [OK]
- Not extending HttpException
- Not calling super() with message and status
- Using plain functions instead of classes
class ForbiddenException extends HttpException {
constructor() {
super('Access denied', 403);
}
}Solution
Step 1: Read the constructor call
The constructor calls super with message 'Access denied' and status 403.Step 2: Understand HttpException behavior
The second argument to super is the HTTP status code returned when exception is thrown.Final Answer:
403 -> Option CQuick Check:
Status code = 403 from super() call [OK]
- Confusing message with status code
- Assuming default 500 status
- Ignoring the status argument in super()
class BadRequestException extends HttpException {
constructor() {
super('Bad request');
}
}Solution
Step 1: Check super() arguments
The super() call only has a message string, but HttpException requires message and status code.Step 2: Understand HttpException constructor
HttpException constructor needs both message and HTTP status code to work correctly.Final Answer:
Missing HTTP status code in super() call -> Option AQuick Check:
super() needs message + status [OK]
- Forgetting the status code argument
- Thinking message alone is enough
- Misunderstanding HttpException constructor
class CustomErrorException extends HttpException {
constructor() {
super(
{ errorCode: 1234, message: 'Custom error' },
400
);
}
}Solution
Step 1: Review HttpException constructor usage
HttpException accepts either a string or an object as the first argument for the response body.Step 2: Confirm JSON response with status code
Passing an object with errorCode and message as first argument and 400 as second is valid and sends JSON response with status 400.Final Answer:
This code correctly sends a JSON object with errorCode and message and HTTP 400 status -> Option AQuick Check:
HttpException supports object response + status [OK]
- Thinking only strings allowed in super()
- Putting status code inside JSON object
- Believing custom exceptions can't send JSON
Ready to prove it?
Pass the test and this pattern moves unknown
