feat(common): allow passing errorCode in HttpExceptionOptions

[lhj0621]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Note: This is an API change that would benefit from documentation. I can create a follow-up PR for the docs if this feature is approved.

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Other... Please describe:

What is the current behavior?

Currently, HttpException provides a status and a message to describe an error. While this is effective for general error reporting, it lacks a mechanism for conveying a specific, machine-readable error cause.

For example, multiple validation failures (e.g., invalid email, weak password) might all result in a 400 Bad Request. Without a distinct error code, client applications are forced to parse the human-readable error message string to determine the specific cause, which is brittle and unreliable.

Issue Number: N/A

What is the new behavior?

This PR introduces a new optional errorCode property to HttpExceptionOptions. This allows developers to attach a specific, machine-readable error code to an exception.

This errorCode is then included in the JSON response body, enabling clients to programmatically and reliably handle different error scenarios without parsing fragile message strings.

Example Usage:

throw new BadRequestException('The password is too short.', {
  errorCode: 'PASSWORD_TOO_SHORT'
});

Example Response:

{
  "statusCode": 400,
  "message": "The password is too short.",
  "error": "Bad Request",
  "errorCode": "PASSWORD_TOO_SHORT"
}

Does this PR introduce a breaking change?

• Yes
• No

This change is fully non-breaking as the errorCode property is optional and does not affect any existing functionality.

Other information

This feature enhances NestJS's capabilities for building mature, large-scale applications by aligning it with common API design best practices.

[coveralls]

Pull Request Test Coverage Report for Build 0b78bf17-bf06-43d6-95c7-979d7875201a

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 88.734%

---

Totals
Change from base Build dd6f1ede-44c2-4f19-806c-d99b5c3ba328:	0.0%
Covered Lines:	7270
Relevant Lines:	8193

---

💛 - Coveralls

[kamilmysliwiec]

Why don't you create a dedicated exception class in your project instead? For instance, PasswordToShortException

[lhj0621]

Why don't you create a dedicated exception class in your project instead? For instance, PasswordToShortException

Hi, thank you for the insightful feedback! That's a very valid point.
I agree that specific exception classes like PasswordTooShortException should absolutely live within an application's domain, not the framework's core. My apologies if my PR description wasn't clear enough on this.
The goal of this PR is not to add any specific exceptions to NestJS.
Instead, the motivation is to provide a generic and standardized mechanism within the core HttpException for developers to attach a machine-readable errorCode. Currently, if a developer wants this common feature, they have to create their own custom HttpException subclass in every project just to add this capability, leading to boilerplate code.
Without this PR (The DIY approach):
A developer would have to write this in their project:

// Boilerplate code in the user's project
class AppHttpException extends HttpException {
  constructor(message: string, status: number, public readonly errorCode: string) {
    super({ message, errorCode, statusCode: status, error: 'Bad Request' }, status);
  }
}

// And use it like this:
throw new AppHttpException('Password is too short', 400, 'PASSWORD_TOO_SHORT');

With this PR:
The developer can directly use the built-in feature without any boilerplate:

// Cleaner, framework-supported way
throw new BadRequestException('Password is too short', { 
 errorCode: 'PASSWORD_TOO_SHORT' 
});

By integrating this small, non-breaking feature directly into the framework, we empower all NestJS developers with a cleaner, more robust way to implement this best practice. It enhances the framework itself for building large-scale APIs where structured error handling is crucial.
I hope this clarifies the intention. Please let me know what you think!