Having a method whose return type depends on whether the second argument was provided or no looks weird. Thus, both code paths are not sharing the logic (except for the exception flattening, but this is not a big deal). So I suggest using a different method instead for the PSR7 case (thus, we are modifying a response for PSR7, not creating it).

and btw, your implementation actually depends of how the response passed as argument looks like. It might do weird things if it is not a basic empty response.

This code also isn't very easy to use, as it's called from:

     private function failSafeHandle(\Exception $exception)
     {
         if (class_exists('Symfony\Component\HttpFoundation\Response', false)) {
             $response = $this->createResponse($exception);
             $response->sendHeaders();
             $response->sendContent();
         } else {
             $this->sendPhpResponse($exception);
         }
     }

So one would need to override this class and failSafeHandle, which will be quite a struggle as it's a private method...

@wouterj there is no need to reach this code. It's an implementation detail that is kept only for BC.

@stof OK for the test and new method. But for expecting an empty response, does psr-7 offer any other way?

PR is ready. I did not create a new method, because I prefer not cluttering the class with unused methods, nor can't I find a better name for it.
PSR-7 being interfaces only (+ immutability) means that for creating a response, you must start from some implementation, then use it as a prototype.
It's not a hard stand and I'm ok to change my mind about that, but this is my preference.

An other way to PSR-7 support is to remove HttpFoundation support by deprecating createResponse!
The method is not used by Symfony itself.

@nicolas-grekas what is the use case of this method actually ?

That's a good question :) @fabpot any idea?

Let's deprecate this method in 2.8 and remove it in 3.0.

So, you need to remove the only usage of it.

Fine, closed in favor of #15418