Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This provides error handler middlewares for JSON and HTML.
There are mainly three reasons I implemented this as a middleware.
There was already a default HTML page for the error 404, defined in
Opium.App
. So this middleware can be seen as a generalization of this error page to every error code.The error handler defined in
Server_connection
will only work when exceptions are raised.The exception does not contain the error code, and reporting errors other than exceptions are reserved to Httpaf internal uses (functions are not exposed)
so if users want to rely on the Server_connection error handler, they are limited to using the internal server error, which seems pretty limited.
I think most of the time, users will return an HTTP response with an error code instead of raising an exception. If there is no error handler, they will have to write their own.
Most applications will end up having to do this at some point, but following the design goal "A programmer should be instantly productive when starting out.", I thought it would be nice to provide good defaults.
A lot of applications have different types of entry points. It is common to provide JSON endpoints as well as HTML endpoints in the same application.
The error handlers will be different depending on the content type of the endpoint, and a middleware provides this flexibility as it can be applied to specific routes.
I also provided a way to easily override the error handling of specific status code with #96 in mind. One can override an error with the following syntax:
which, IMHO, is a bit more user friendly than implementing a custom Httpaf error handler.
Error handling is an important part of a web framework and I think it's crucial that we find a good balance between convention, productivity, and flexibility. So I'm happy to experiment on other solutions to provide good defaults if the middleware solution seems weird to you.