When we throw an exception in our Symfony applications, we can be quite lazy and have Symfony catch it for us and display a nice error message to our user. This is great, most of the time we don’t want to show detailed exception messages to the user. We certainly wouldn’t expose any sensitive information like database names for example. Sometimes however, we want to use our exception messages as a way to communicate back to our user that something went wrong.
The Symfony standard distribution will display its
content to the user when an exception is thrown and not caught explicitly. This is great, apart from the fact that we
may want some exceptions to have their message displayed in the error template to explain to the user what went wrong.
Symfony handles exceptions using the
kernel.exception event, which means we too can hook into this in our container
configuration and intercept the exception handling with our own logic. Let’s start by creating our 500 error template
that will be used to display the exception message to the user. This will reside in
app/Resources/TwigBundle/views/Exception/error500.html.twig, and will only be used for exceptions and error responses
(500 error codes)…
This is just a simple example of what you can do with your template. If you are wondering what that
template variable is, we set that in our exception handler which will look something like below…
The aim of any exception handler in Symfony is to provide a
Response object (or throw another more relevant exception)
which can be returned for the request. In our handler we return a
Response instance (created via the templating
engine) with a single template variable
status_text containing our exception message. Symfony will then return our
response to the client that made the request.
To finish off we need to hook our exception handler into our service container with some configuration. If you are using XML for your configuration it would look something like this…
<tag /> XML tag tells Symfony that this is an event listener, and that it wants to subscribe to any
kernel.exception events fired during the life cycle of the application. Providing your service container configuration
is loaded, you should see your custom exception template after a container recompile (
Obviously, this will only be used in a non-debug environment because Symfony will display the much more verbose
exception view in debug mode.
Being Careful Exposing Exception Messages
Although this is a quick way of getting exception messages back to your user, it would be wise to take this one step
further and use a custom
Exception class that indicates that it is okay to display the exception message to the user.