We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Currently, any @ApiResponse decorator has a never type by default. This can be very vexatious in case of using type-safe OpenAPI clients.
@ApiResponse
never
@ApiOkResponse({description: "Something happened"}) @ApiBadRequestResponse({description: "Something went wrong"}) @Get() someTest() { // ... throw new HttpException('Some test', 400); // ... }
Will result in the following types being generated:
{ responses: { 200: // ... 400: never } }
Perhaps implementing a "default exception type" or a way of globally setting the default return type would help.
No response
This allows the swagger to auto-generate (primarily) exceptions more streamlined to default HttpException results (see examples below).
A generic HttpException response.
{ message: string, statusCode: number }
Or, for example, a class-validator exception.
class-validator
{ message: string[], error: string, statusCode: number }
The text was updated successfully, but these errors were encountered:
+1
Sorry, something went wrong.
No branches or pull requests
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
Currently, any
@ApiResponse
decorator has anever
type by default. This can be very vexatious in case of using type-safe OpenAPI clients.Will result in the following types being generated:
Describe the solution you'd like
Perhaps implementing a "default exception type" or a way of globally setting the default return type would help.
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
This allows the swagger to auto-generate (primarily) exceptions more streamlined to default HttpException results (see examples below).
A generic HttpException response.
Or, for example, a
class-validator
exception.The text was updated successfully, but these errors were encountered: