Uncaught Errors
Given that it is not possible to process all uncaught errors sensibly, the best way to deal with them is to crash.
Catching Errors In Promises
In Node.js, unhandled promise rejections (that is, without a handler) can also cause memory and file descriptor leaks. While unhandledRejection
is deprecated in Node.js, unhandled rejections will not throw, and still potentially leak. You should use a module like make-promises-safe
to ensure unhandled rejections always throw.
If you are using promises, you should attach a .catch()
handler synchronously.
Fastify follows an all-or-nothing approach and aims to be lean and optimal as much as possible. The developer is responsible for making sure that the errors are handled properly.
Errors In Input Data
Most errors are a result of unexpected input data, so we recommend validating your input data against a JSON schema.
Catching Uncaught Errors In Fastify
Fastify tries to catch as many uncaught errors as it can without hindering performance. This includes:
- synchronous routes, e.g.
app.get('/', () => { throw new Error('kaboom') })
async
routes, e.g.app.get('/', async () => { throw new Error('kaboom') })
The error in both cases will be caught safely and routed to Fastify’s default error handler for a generic 500 Internal Server Error
response.
To customize this behavior you should use setErrorHandler
.
From the :
If you have defined a custom error handler for using setErrorHandler
the error will be routed there. otherwise, it will be routed to Fastify’s generic error handler.
Some things to consider in your custom error handler:
-
- objects are serialized, triggering the
preSerialization
lifecycle hook if you have one defined - strings, buffers, and streams are sent to the client, with appropriate headers (no serialization)
- objects are serialized, triggering the
You can throw a new error in your custom error handler
- errors (new error or the received error parameter re-thrown) - will trigger the
onError
lifecycle hook and send the error to the user
- errors (new error or the received error parameter re-thrown) - will trigger the
FST_ERR_BAD_URL
The router received an invalid url.
FST_ERR_CTP_ALREADY_PRESENT
The parser for this content type was already registered.
FST_ERR_CTP_BODY_TOO_LARGE
The request body is larger than the provided limit.
This setting can be defined in the Fastify server instance:
FST_ERR_CTP_EMPTY_TYPE
The content type cannot be an empty string.
FST_ERR_CTP_INVALID_CONTENT_LENGTH
Request body size did not match Content-Length.
FST_ERR_CTP_INVALID_HANDLER
An invalid handler was passed for the content type.
FST_ERR_CTP_INVALID_MEDIA_TYPE
The received media type is not supported (i.e. there is no suitable Content-Type
parser for it).
FST_ERR_CTP_INVALID_PARSE_TYPE
The provided parse type is not supported. Accepted values are string
or buffer
.
FST_ERR_CTP_INVALID_TYPE
The should be a string.
FST_ERR_DEC_ALREADY_PRESENT
A decorator with the same name is already registered.
FST_ERR_DEC_MISSING_DEPENDENCY
FST_ERR_HOOK_INVALID_HANDLER
The hook callback must be a function.
FST_ERR_HOOK_INVALID_TYPE
The hook name must be a string.
FST_ERR_LOG_INVALID_DESTINATION
The logger accepts either a 'stream'
or a 'file'
as the destination.
FST_ERR_PROMISE_NOT_FULFILLED
A promise may not be fulfilled with ‘undefined’ when statusCode is not 204.
FST_ERR_REP_ALREADY_SENT
A response was already sent.
FST_ERR_REP_INVALID_PAYLOAD_TYPE
Reply payload can be either a string
or a Buffer
.
FST_ERR_SCH_ALREADY_PRESENT
A schema with the same $id
already exists.
FST_ERR_SCH_MISSING_ID
The schema provided does not have $id
property.
FST_ERR_SCH_SERIALIZATION_BUILD
The JSON schema provided for serialization of a route response is not valid.
FST_ERR_SCH_VALIDATION_BUILD
The JSON schema provided for validation to a route is not valid.
FST_ERR_SEND_INSIDE_ONERR
You cannot use send
inside the onError
hook.
FST_ERR_SEND_UNDEFINED_ERR
Undefined error has occurred.