All the examples shown in this article use the same KernelEvents::EXCEPTION
event for consistency purposes. In your own application, you can use any event
and even mix several of them in the same subscriber.

// src/EventListener/ExceptionListener.phpnamespaceApp\EventListener;useSymfony\Component\HttpKernel\Event\GetResponseForExceptionEvent;useSymfony\Component\HttpFoundation\Response;useSymfony\Component\HttpKernel\Exception\HttpExceptionInterface;classExceptionListener{publicfunctiononKernelException(GetResponseForExceptionEvent$event){// You get the exception object from the received event$exception=$event->getException();$message=sprintf('My Error says: %s with code: %s',$exception->getMessage(),$exception->getCode());// Customize your response object to display the exception details$response=newResponse();$response->setContent($message);// HttpExceptionInterface is a special type of exception that// holds status code and header detailsif($exceptioninstanceofHttpExceptionInterface){$response->setStatusCode($exception->getStatusCode());$response->headers->replace($exception->getHeaders());}else{$response->setStatusCode(Response::HTTP_INTERNAL_SERVER_ERROR);}// sends the modified response object to the event$event->setResponse($response);}}

Symfony follows this logic to decide which method to execute inside the event
listener class:

If the kernel.event_listener tag defines the method attribute, that's
the name of the method to be executed;

If no method attribute is defined, try to execute the method whose name
is on + "camel-cased event name" (e.g. onKernelException() method for
the kernel.exception event);

If that method is not defined either, try to execute the __invoke() magic
method (which makes event listeners invokable);

If the _invoke() method is not defined either, throw an exception.

Note

There is an optional attribute for the kernel.event_listener tag called
priority, which is a positive or negative integer that defaults to 0
and it controls the order in which listeners are executed (the higher the
number, the earlier a listener is executed). This is useful when you need to
guarantee that one listener is executed before another. The priorities of the
internal Symfony listeners usually range from -255 to 255 but your
own listeners can use any positive or negative integer.

Another way to listen to events is via an event subscriber, which is a class
that defines one or more methods that listen to one or various events. The main
difference with the event listeners is that subscribers always know which events
they are listening to.

In a given subscriber, different methods can listen to the same event. The order
in which methods are executed is defined by the priority parameter of each
method (the higher the number the earlier the method is called). To learn more
about event subscribers, read The EventDispatcher Component.

The following example shows an event subscriber that defines several methods which
listen to the same kernel.exception event:

That's it! Your services.yaml file should already be setup to load services from
the EventSubscriber directory. Symfony takes care of the rest.

Tip

If your methods are not called when an exception is thrown, double-check that
you're loading services from
the EventSubscriber directory and have autoconfigure
enabled. You can also manually add the kernel.event_subscriber tag.

A single page can make several requests (one master request, and then multiple
sub-requests - typically by How to Embed Controllers in a Template). For the core
Symfony events, you might need to check to see if the event is for a "master" request
or a "sub request":

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

// src/EventListener/RequestListener.phpnamespaceApp\EventListener;useSymfony\Component\HttpKernel\Event\GetResponseEvent;classRequestListener{publicfunctiononKernelRequest(GetResponseEvent$event){if(!$event->isMasterRequest()){// don't do anything if it's not the master requestreturn;}// ...}}

Certain things, like checking information on the real request, may not need to
be done on the sub-request listeners.

Listeners and subscribers can be used in the same application indistinctly. The
decision to use either of them is usually a matter of personal taste. However,
there are some minor advantages for each of them:

Subscribers are easier to reuse because the knowledge of the events is kept
in the class rather than in the service definition. This is the reason why
Symfony uses subscribers internally;

Listeners are more flexible because bundles can enable or disable each of
them conditionally depending on some configuration value.