Masonite error handling is based on the ExceptionHandler
class which is responsible for handling all exceptions thrown by your application.
All exceptions are handled by the ExceptionHandler class which is bound to the Service Container through exception_handler
key.
This handler has a logic to decide how to handle exceptions depending on the exception type, the environment type, the request accepted content type and the configured exception handlers.
This handler has by default one driver Exceptionite which is responsible of handling errors in development by providing a lot of context to help debug your application.
When Debug mode is enabled all exceptions are rendered through Exceptionite HTML debug page.
When disabled, the default errors/500.html
, errors/404.html
, errors/403.html
error pages are rendered depending on error type.
Never deploy an application in production with debug mode enabled ! This could lead to expose some sensitive configuration data and environment variables to the end user.
When an exception is raised it will be caught by the ExceptionHandler. Then the following cycle will happen:
A masonite.exception.SomeException
event will be fired.
A specific ExceptionHandler will be used if it exists for the given exception.
Exceptionite will then handle the error by rendering it in the console
and with the Exceptionite JSON response if accepted content is application/json
else with the Exceptionite HTML error page
A masonite.exception.SomeException
event will be fired.
A specific ExceptionHandler will be used if it exists for the given exception. In this case the default ExceptionHandler won't process the exception anymore.
If exception is an HTTP exception it will be handled by the HTTPExceptionHandler which is responsible for selecting an error template (errors/500.html
, errors/404.html
, errors/403.html
) and rendering it.
If exception is a Renderable exception it will be rendered accordingly.
Else this exception has not been yet handled and will be handled as an HTTP exception with 500 Server Error status code.
To report an exception you should simply raise it as any Python exceptions:
There are different type of exceptions.
Simple exceptions will be handled as a 500 Server Error if no custom exceptions handlers are defined for it.
HTTP exceptions are standard exceptions using frequently used HTTP status codes such as 500, 404 or 403.
Those exceptions will be rendered by the HTTPExceptionHandler
with the corresponding status code and the corresponding default error template if it exists in errors/
. (Note that in debug mode this template won't be rendered and the default Exceptionite error page will be rendered instead).
The following HTTP exceptions are bundled into Masonite:
AuthorizationException (403)
RouteNotFoundException (404)
ModelNotFoundException (404)
MethodNotAllowedException (405)
In a default Masonite project, existing errors views are errors/404.html
, errors/403.html
and errors/500.html
. Those views can be customized.
You can also build a custom HTTP exception by setting is_http_exception=True
to it and by defining the get_response()
, get_status()
and get_headers()
methods:
When the above exception is raised, Masonite will look for the error view errors/401.html
in the default project views folder and will render it with a 401
status code. The content of get_response()
method will be passed as the message
context variable to the view.
If this view does not exist the HTML response will be directly the content of the get_response()
method with a 401
status code.
If you want more flexibility to render your exception without using the HTTPExceptionHandler above, you can just add a get_response()
method to it. This method will be given as first argument of response.view()
, so that you can render simple string or your own view template.
Here when raising this exception in your code, Masonite will know that it should render it by calling the get_response()
method and here it will render as a string containing the message raised.
Note that you can also set an HTTP status code by adding - as for HTTP exceptions - the get_status()
method to the exception.
Existing Exception Handlers are:
HTTPExceptionHandler
DumpExceptionHandler
You can build your own Exception Handlers to override the way Masonite handles an exception that is thrown or to add new behaviours.
A handler is a simple class with a handle()
method that Masonite will call when a specific exception is thrown by the application.
As an example, you could handle specifically ZeroDivisionError
exceptions that could be thrown by your application. It will look like this:
The name of the class can be whatever you like. In the handle method you should manually return a response by using the response class.
You will then need to register the class to the container using a specific key binding. The key binding will be {exception_name}Handler
. You can do this in your Kernel file.
To register a custom exception handler for our ZeroDivisionError
we would create a binding that looks like this:
You can add this binding in your AppProvider or in Kernel.py
.
Now when your application throws a ZeroDivisionError
, Masonite will use your handler rather than Masonite's own exception handlers.
If you want to hook up an error tracking service such as Sentry or Rollbar you can do this through event listeners: each time an exception is raised, a masonite.exception.{TheExceptionType}
is fired, allowing to run any custom logic.
First create a listener to run your custom logic:
In a Service Provider you then need to register this listener: