The Critical kernel.exception Event Listeners

Hey Volodymyr T.!

Ha! Good eye! I purposely didn't talk about it because it's not that important and it IS a bit confusing/complex. The flow is this:

A) Somewhere in the main request, an exception is thrown
B) This causes ErrorListener::onKernelException() to be called
C) Inside this method (via the private duplicateRequest() method) a new Request object is created and the exception is added as an exception request attribute.
D) The Request created above is handled via a sub-request. This starts the whole request-response flow process again. The job of this sub-request is to render the error page (via the error controller)
E) Before the error controller is executed, the onControllerArguments() method is called (this was also called on the main request before the controller, but it didn't do anything then.
F) onControllerArguments() first finds which position the $exception argument is in in the error controller (that's the $k variable). Because remember, at this point, the controller arguments HAVE been determined, and since there is a exception key in the request attribute, if there is an $exception argument in the controller, then those have been matched up.
G) The method THEN looks to see what the type-hint is on the $exception argument. If there is NONE or if it is type-hinted with FlattenException, then the method creates a FlattenException from the exception and uses that as the argument.

So that's a LONG way of saying that this code allows your error controller to have an $exception argument and choose between the real exception object and a FlattenException object via the type-hint. How crazy is that? I'm not sure the exact history behind this - it comes from the introduction of the ErrorRenderer component - but apparently there are reasons to sometimes want one class or the other.

Cheers!

Thanks for the detailed explanation. It now totally became clear! I stumbled to grasp that there is a possibility for a custom error controller which might have something else in its list of arguments than the public function __invoke(\Throwable $exception): Response of a core "ErrorController::__invoke()" method.

Hey Daniil G.!

Excellent question! On a high level, the ErrorListener class is a service that is registered by Symfony. It's first argument to __construct is $controller. So, on a high level, when Symfony registers ErrorListener as a service, it sets the string error_controller as its first argument. You can see it right here: https://github.com/symfony/symfony/blob/75e71e3bbefffe1e67d80e842d66721b98f6a531/src/Symfony/Bundle/FrameworkBundle/Resources/config/web.xml#L81

In reality, you'll notice that the first argument is a parameter - %kernel.error_controller%. This touches on the type of stuff that we'll talk about in our next deep dive tutorial, which will be all about the Symfony container. But basically, you can set the error controller string via this config:

framework:
    error_controller: 'some_other_controller::renderError'

This is not usually something that you set in your app, and it defaults to error_controller. Whatever value is set for this (your custom value or the default error_controller) is eventually set to that parameter - https://github.com/symfony/symfony/blob/75e71e3bbefffe1e67d80e842d66721b98f6a531/src/Symfony/Bundle/FrameworkBundle/DependencyInjection/FrameworkExtension.php#L238 - which is passed as the first argument to ErrorListener, which sets it on the $this->controller property. How fun is that ;).

That's a quick and dirty explanation - let me know if it helps!

Cheers!

Thanks! Good explanation.

Hey Diarill

Your solution looks good, but does your issue related to course? or it was question about your own implementation? And does it related to this chapter? It's important because when you say that something not work as expected we should know is it our course code broken? or it's just your theoretical question.

Cheers!

Hi Vladimir Sadicov
no! my problem has nothing to do with the course or this video. But by following this project (The_Spacebar) from the start, I imagined that I could find myself in the situation where (for example in the case of online application submission for a position, we would not want a candidate to submit multiple times) a unique post for each account.

Hey Diarill

Sorry for late reply. Thanks for approve that course is ok. And as I said you solution is pretty good for it, probably I would recommend you to refactor it in for example getUniqueReference() and so on. It's really depends on your needs!

Cheers! and Enjoy the courses!

Hey Diarill!

> When I imagine a simple senariot, I run into a problem. I assumed that a user should only publish one article, so I added the unique user_id constraint in the Article entity. But when I launch the fixtures, boom !!! "Integrity constraint violation: 1062 Duplicate entry ".

Hmm. If you only want a user to publish one article... but executing your fixtures creates this error, then it sounds like your fixtures are written incorrectly - they are assigning more than one article to a user. Is it possible that your comment is being displayed below the wrong article? This question seems unrelated... it actually kind of seems related to using Alice YAML fixtures... which is why I might be confused :). Let me know!

Cheers!