-
-
Notifications
You must be signed in to change notification settings - Fork 20
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
should this package expose FastifyError? #17
Comments
My recommendation is to never use I can see why a lot of people would like to support this pattern. The way this is implemented it does not have a generic |
indeed, which is why I never use Jest 😉
whichever class is exported, can then be used later to identify the error instance, since it will have to be import-ed/require-ed directly ... |
Yes exactly! Would you like to send a PR to fastify? |
Well, because of FST_ERR_CTP_EMPTY_TYPE: createError(
'FST_ERR_CTP_EMPTY_TYPE',
'The content type cannot be an empty string',
500,
TypeError // We need to change this params to generic `FastifyError` class and we can't pass `TypeError` anymore
) |
What about the Boom approach: adding |
That would work for me. |
Do not make it an |
I am not sure how this plays out with my proposal. Is this an alternative approach? |
function isFastifyError(obj) {
return Object.prototype.toString.call(obj) === '[object FastifyError]'
} The |
Yes. That's why I don't want to use it either. I am firmly against the instanceof operator. I prefer Boom's approach for that reason. It is better to ship the check function directly inside this lib from the DX perspective. |
Sorry for phrasing it badly. What I meant is to expose a function that will check our own known property. 👌 |
What i wrote in the corresponding PR: I could do that instead, if we agree on |
So, what is the recommended way to check if error is a FastifyError? I'm implementing optional JWT authentication with @fastify/jwt like so: fastify.decorate<onRequestAsyncHookHandler>('authenticateUserOptional', async function (request) {
try {
await request.userJwtVerify()
} catch (error: unknown) {
// Is it the recommended way?
// Ignore when token is missing
if (error instanceof Error && 'code' in error && error.code === 'FST_JWT_BAD_REQUEST') {
return
}
throw error
}
}) |
This feels like a terrible recommended way to handle errors - and the documentation method does not allow us to easily handle all error cases without a bunch of if/else statements using
I find myself having to do this
To check if its a fastify error but then if i try to do : function handleFastifyError(error: FastifyError) {
switch (error.code) {
case errorCodes.FST_ERR_ROUTE_METHOD_INVALID:
case errorCodes.FST_ERR_ROUTE_METHOD_NOT_SUPPORTED: {
break;
}
case errorCodes.FST_ERR_CTP_INVALID_TYPE:
case errorCodes.FST_ERR_CTP_EMPTY_TYPE:
case errorCodes.FST_ERR_MISSING_CONTENTTYPE_SERIALIZATION_FN:
case errorCodes.FST_ERR_CTP_INVALID_MEDIA_TYPE: {
break;
}
case errorCodes.FST_ERR_CTP_BODY_TOO_LARGE: {
break;
}
case errorCodes.FST_ERR_NOT_FOUND: {
return
break;
}
default:
break;
}
} you cant do `case errorCodes.
Using a string comparison directly is not ideal as it doesn't protect against upstream code changes in future unless
|
🚀 Feature Proposal
should export
FastifyError
function so it can be used witherr instanceOf FastifyError
in plain JavaScriptis there a reason this is not currently exposed? seems like the use-case is primarily focused on TypeScript, any reason we shouldn't have access to it for plain JS.
Motivation
in a Fastify errorHandler, you want to intercept errors and check what they are
Example
The text was updated successfully, but these errors were encountered: