express-openapi-validator
express-openapi-validator copied to clipboard
cdimascio
Open-Api Custom Error
Is your feature request related to a problem? Please describe. We are moving the company to use the lib but one issue we struggle with is identifying the validator errors to be able to convert them properly to our own custom errors. The code to do so is kind of long and ugly just to know if it's an open-api error.
Describe the solution you'd like I would love a custom error that has a boolean or function that returns a boolean to do an easy check to know it's an open-api error. Many libraries recently have been doing something like error.isAxiosError or hapi.isBoom(). maybe we can have error.isOpenApi?
Describe alternatives you've considered
Additional context
I'm open to suggestions here. Note that most of the errors returned from the generator are sourced from here.
Feel free to take a stab at it. PRs are certainly welcome. Note that the referenced code should get a good jumpstart on the errors. We'll alsol need to do a brief search of the codebase to ensure we've got them all
i see no improvement in the proposed solution for the use case i described in my issue. I still have to do the checks that i want to avoid. I could also write a function isValidationError(error) that checks, if the error is a validation error, so I have not much benefits from error.isOpenApi.
As an end user, I prefer my solution as it is simply more explicit. Furthermore, we already have the onError prop for responseValidation, which would also keep the interface more consistent.
@setaman You have to somehow identify the error. How do you want to do it without asking/checking? Unique error property is fine in my eyes.
@crudo no need to check anything, if you have already defined an error handler that formats the validation error as you need. You can just propagate it in your error handler middleware. Otherwise you could write a functions (like i did to just improve the code) that identifies the error:
const isOpenAPISpecValidationError = (err) => err.errors && err.status,
So to call isOpenAPISpecValidationError(err) or err.isOpenApi makes not much difference. You still have to check.
@crudo i believe he's attempting to just provide a custom error handler function so that he knows that if that function is called it can only be an openApi error so he wouldn't need to check. In my case I just have a global error handler that catches several different error types from different libs and then builds custom errors from them. I just need to know which is which
@joeylgutierrez Yep. I agree. My use case is closer to yours. I have multiple possible sources of errors and has to distinguish between them.
@setaman based on the discussion, it appears these are indeed two separate requests. I will reopen the other.
@joeylgutierrez I have similar requirement to yours. My current workaround is adding an error handling middleware right after openapi validator (since express middleware runs in order, and my other middlewares before this error handler do not throw errors), but not sure if your project allows doing things this way.
