Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

feat(common): allow passing errorCode in HttpExceptionOptions#15525

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
lhj0621 wants to merge1 commit intonestjs:master
base:master
Choose a base branch
Loading
fromlhj0621:feat/add-error-code

Conversation

@lhj0621
Copy link

PR Checklist

Please check if your PR fulfills the following requirements:

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 astatus and amessage 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 a400 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 optionalerrorCode property toHttpExceptionOptions. This allows developers to attach a specific, machine-readable error code to an exception.

ThiserrorCode 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:

thrownewBadRequestException('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 theerrorCode 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
Copy link

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

Details

  • 0 of0 changed or added relevant lines in0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at88.734%

TotalsCoverage Status
Change from baseBuild dd6f1ede-44c2-4f19-806c-d99b5c3ba328:0.0%
Covered Lines:7270
Relevant Lines:8193

💛 -Coveralls

@kamilmysliwiec
Copy link
Member

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

@lhj0621
Copy link
Author

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 projectclassAppHttpExceptionextendsHttpException{constructor(message:string,status:number,publicreadonlyerrorCode:string){super({ message, errorCode,statusCode:status,error:'Bad Request'},status);}}// And use it like this:thrownewAppHttpException('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 waythrownewBadRequestException('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!

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@lhj0621@coveralls@kamilmysliwiec

[8]ページ先頭

©2009-2025 Movatter.jp