add error management for failed Validation Pipes #169
Conversation
| useValue: new ValidationPipe({ | ||
| exceptionFactory: (errors) => { | ||
| const logger = new Logger('ValidationPipe') | ||
| const errorMessages = errors.map((error) => ({ | ||
| property: error.property, | ||
| constraints: error.constraints | ||
| })) | ||
| logger.error(JSON.stringify(errorMessages)) | ||
| return new BadRequestException('Validation failed') | ||
| } | ||
| }) |
There was a problem hiding this comment.
There's a better way to solve that problem than adding a custom handler to the validation pipe. Moreover, the validation pipe already throws a BadRequestException, by rethrowing the error you're losing information. Never catch an error and throw a new one without its origin; otherwise you lose the stack trace – that's crucial for debugging.
The NestJS architecture calls this component Exception Filter.
Please reference the application-exception.filter.ts from the Armory application. However, instead of catch ApplicationException you want to filter by Nest's HttpException.
See also Catch Everything section in the documentation.
| @@ -0,0 +1,52 @@ | |||
| import { ArgumentsHost, Catch, ExceptionFilter, LogLevel, Logger } from '@nestjs/common' | |||
There was a problem hiding this comment.
Please, port the test file from the Armory to the Policy Engine project as well.
| const withGlobalFilters = | ||
| (configService: ConfigService<Config, true>) => | ||
| (app: INestApplication): INestApplication => { | ||
| app.useGlobalFilters(new HttpExceptionFilter(configService), new ApplicationExceptionFilter(configService)) |
There was a problem hiding this comment.
[Not an action]
When setting global filters in your bootstrap, think of them as a framework version of Node's unhandledRejection. They act as a final catch before things blow up.
The side effect of including global filters in the bootstrap is that if you assemble an application using a module, it won't have the filter registered. An example of assembling the application by module is in tests where we don't need the server running. In other words, none of the E2E tests will have this filter, which can lead to confusion.
What you're essentially saying is: "I want my SERVER to have these filters," but you're not adding them to your business logic unless its public interface is a server.
That's why some modules, like the OrchestrationModule, set the same filters as a dependency.
There was a problem hiding this comment.
Got it, good lesson here ! Ty
Co-authored-by: William Calderipe <wcalderipe@gmail.com>
* add error management for failed Validation Pipes * format * test exception on ping controller * registered exception filters to policy-engine * format * Update apps/armory/src/shared/filter/application-exception.filter.ts Co-authored-by: William Calderipe <wcalderipe@gmail.com> * ported filter test file --------- Co-authored-by: William Calderipe <wcalderipe@gmail.com>
No description provided.