-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Implement FastifyErrorCode enum #5437
base: main
Are you sure you want to change the base?
Conversation
Export a `FastifyErrorCode` object in errors which allows better handling of error codes in the case a Fastify error code occurs Signed-off-by: Braden Napier <bradynapier+github@gmail.com>
Note that I am personally more in favor of the
as this allows using it like a
However, I dont see that pattern used much outside my own codebases so I went with the more common pattern |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes in this file will be very annoying to maintain. I would much rather see a method for inspecting error objects as outlined in fastify/fastify-error#17 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It appears that way, yet it doesn't change much. You still need to define the string manually twice then again in the types.
It's not ideal, no. However even with the IsFastifyError implemented there is still no way to then easily narrow the specific errors you want to single out for handling.
The other option which requires almost zero cost to maintain is to generate the enumeration from the code's object directly - but the code's object still requires similar maintenance to this PR
In our case there are some cases we want exposed to users with our error messaging while others are internal errors we only wish to log internally while returning an internal server error to the user.
In my opinion both this and the isFastify concepts are required and complement each other.
Doing 20+ instanceof checks over a switch that can return never case to warn me if new errors are added in future that I am not handling is ideal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The current code just double the works to do when adding a new error.
I am not oppose to update the types
but in Javascript
side, does it necessary for the change?
You can use Object.keys
to generate the enum
if you need.
Could clarify what problem are you trying to solve here? Maybe with an example. |
Checklist
npm run test
andnpm run benchmark
and the Code of conduct
Summary
Currently its quite a pain to work with
FastifyError
due to the fact there is no programmatic way to clearly parse an error for a specific type.You either have to:
instanceof
checks against each check individually in an errorHandlerfunction.name.toString()
error.code.startsWith('FST')
to identify fastify errors against internal errorsWhile I agree that this should also include changes to
@fastify/errors
to include something likeerror.isFastifyError
checks in typescript, the TypeScript side of this is equally as painful:FastifyError
checks just to make it work such as:error instanceof Error && 'code' in error && error.code === 'FST_JWT_BAD_REQUEST'
(not type safe if that code were to change , even if that is very unlikely)error instanceof Error && 'code' in error && error.code.startsWith('FST')
Changes Proposed
FastifyErrorCode
enum which is an object (typescript enum pattern) of{ [code]: code }
allowing for runtime checks against possible fastify error codes in their error handlersFastifyErrorCode
type which is identical to the object allowing easily checking in typescript code with strict typingFastifyErrorCode
enum to construct thecodes
object directly, making it the source of truthThis allows for easily handling errors from fastify in that we can now use checks (note that ideally
FastifyError
would havecode
set toFastifyErrorCode
, but i didnt do that as i could see how that might be more controversial due to potential user modifications@fastify/error
This specific PR should also eventually include more changes to make error handling easier against fastify internal errors:
error.isFastifyError
or similar checks which will allow narrowing againstError | FastifyError
withoutinstanceof
checks or the need to use a base error which the maintainer is against (instanceof FastifyError)errorCodes.FST_JWT_BAD_REQUEST.code
as a static property of the constructed error as another way of switching against what error occurred.