Uncaught errors are likely to cause memory leaks, file descriptor leaks and other major production issues. Domains were introduced to try fixing this issue, but they did not. Given the fact that it is not possible to process all uncaught errors in a sensible way, the best way to deal with them at the moment is to crash. In case of promises, make sure to handle errors correctly.
Fastify follows an all-or-nothing approach and aims to be lean and optimal as much as possible. Thus, the developer is responsible for making sure that the errors are handled properly. Most of the errors are usually a result of unexpected input data, so we recommend specifying a JSON.schema validation for your input data.
Note that, while Fastify doesn't catch uncaught errors for you, if routes are declared as
async, the error will safely be caught by the promise and routed to the default error handler of Fastify for a generic
Internal Server Error response. For customizing this behaviour, you should use setErrorHandler.
Fastify Error Codes
The parser for this content type was already registered.
The content type should be a string.
The content type cannot be an empty string.
An invalid handler was passed for the content type.
The provided parse type is not supported. Accepted values are
Request body is larger than the provided limit.
Received media type is not supported (i.e. there is no suitable content-type parser for it).
Request body size did not match Content-Length.
A decorator with the same name is already registered.
The decorator cannot be registered due to a missing dependency.
The hook name must be a string.
The hook callback must be a function.
Logger acceptes either a
'stream' or a
'file' as the destination.
A response was already sent.
You cannot use
send inside the
Reply payload can either be a
string or a
The schema provided does not have
A schema with the same
$id already exists.
No schema with the provided
Promise may not be fulfilled with 'undefined' when statusCode is not 204.