use \Symfony\Component\Debug\Exception\FlattenException instead of \Symfony\Component\HttpKernel\Exception\FlattenException

Thanks! The documentation changes are all great except:

+   * @param \Symfony\Component\Debug\Exception\FlattenException $exception
+   *  The flattened exception
    * @return array
    */
   protected function decodeException(FlattenException $exception) {

There should be a blank line between the @param and the @return.

And technically, this is not a purely documentation issue.

Well, that is kind of up to you. If you add @return then it will take a bit longer for the patch to get reviewed, but we'll end up with better documentation. As long as the changes are confined to this one file, it's not too much out of scope. :)

I only mentioned the need for a blank line in #2 because you had added the @param and didn't add the blank line -- I didn't go through the whole file to check for other standards problems.

Gotta love this line in the patch:

-   * @param Sonfony\Component\HttpFoundation\Request $request
+   * @param \Symfony\Component\HttpFoundation\Request $request

oops. :)

So, this mostly looks pretty good!

    * @return array
+   *   The exception
    */
   protected function decodeException(FlattenException $exception) {

This documentation doesn't seem very enlightening. Also it should end in ".".

Other than that, this looks great. I checked all the @returns and they all seem correct except this one.

Hm... from the interdiff:

    * @return array
-   *   The exception
+   *   The exception that was contained within the FlattenException .
    */
   protected function decodeException(FlattenException $exception) {

Looking at the code for this method, I think the return value is an array of string-substitution tokens for formatting a message about the exception? "The exception that was contained within the exception" doesn't say that to me, and doesn't make much sense?

1. +++ b/core/lib/Drupal/Core/Controller/ExceptionController.php
   @@ -130,10 +136,13 @@ public function on403Html(FlattenException $exception, Request $request) {
   +   * @return \Symfony\Component\HttpFoundation\Response
   +   *   A response object to be sent to the server.
   

   Response objects are sent to the client, not to the server. They're sent FROM the server.

   (This occurs in several places.)

2. +++ b/core/lib/Drupal/Core/Controller/ExceptionController.php
   @@ -316,7 +337,11 @@ public function on405Json(FlattenException $exception, Request $request) {
       * @return array
   +   *   The exception that was contained within the FlattenException .
   

   Extra space at the end of the description.

You missed #10.1. Fixed here.

But... we don't send the response *object* to the client either. We send a *response* to the client, and the object represents that response, right?

Given that we have a type on @return telling us it's an object, how about saying "The response to send to the client."?

No, I don't think so. In all of these exception handlers we are dealing with the response object still, so I think that's accurate. It is not until send() is called on the response that it takes the form of an actual response.

Yes but the docs say "The response object to send to the client". We don't send the response object to the client. We return the response object, and then send a response to the client, right?

Yes, but this bit of the code should not care about what happens to the response IMO. If that's an issue, I would just say 'The response object', and just remove the need for the client talk.

Much better idea. :)

Begone, client! (No other changes than the comment lines and some rebase jitter, so didn't bother with an interdiff.)

Grumble grumble...

Looks good. Looks like just a couple were missed (the JSON ones). Made those tiny changes to make things consistent.

I think this is good to go. Going straight for the RTBC.

23: 2119237-23.patch queued for re-testing.

Well that was one of the funnier issue titles I've read in awhile. :)

Committed and pushed to 8.x. Thanks!