Exception: Serialization of 'Closure' is not allowed in serialize

As errors could put any kind of value into the message it seems to be required to check and filter
out the variables by serializable content. http://stackoverflow.com/questions/5775094/test-if-a-variable-is-seriali... lists some ways to do it, though all feels kind of ugly.

Just struggled over this while working on #1818556: Convert nodes to the new Entity Field API.
One of the errors is buried in LegacyControllerSubscriber::onKernelControllerLegacy():

    // This BC logic applies only to functions. Otherwise, skip it.
    if (is_string($controller) && function_exists($controller)) {
      $new_controller = function() use ($router_item) {
        return call_user_func_array($router_item['page_callback'], $router_item['page_arguments']);
      };
      $event->setController($new_controller);
    }

This leads to following trace in the case of an error:

I'm not sure how to proceed, if we've a chance to catch all closures it would be nice to give serializable closures a try.
But it's likely we need a defensive serializing function to deal with all possible cases, even if we build serialzable closures, in sensitive locations. Maybe something like this:

function drupal_serialize($var) {
  try {
      return serialize($var);
  } 
  catch(Exception $e) {
    $arr = array($value);
    array_walk_recursive($arr, new serializable_closure(function (&$element) {
      if (is_object($element) && get_class($element) == 'Closure') {
        $serializable_closure = new SerializableClosure($element);
        $element = $serializable_closure->serialize();
      }
    }));
    return serialize($arr[0]);
  }
}

Related #1934738: Exception: Serialization of 'Closure' is not allowed in serialize() (line 154 of dblog.module)

Here's a first patch.

Oh, that assertion had a Windows specific file path in it. Now it's generic.

Can someone perhaps explain to me WHY we need to serialize a closure? What exactly is the use case? The legacy url matcher's closure is not a use case, since I cannot imagine why anyone would be serializing that. It's also intended to be removed once everything is ported to the new routing system.

Well it's not that we need to support it, though when you throw an exception/error and somewhere in the stack is a db connection,
you can't log the error at the moment. This hasn't been a problem in D7, because you never actually stored the db connection somewhere.

Storing the DB connection? Wha? Now I'm even more confused.

With "storing" i wanted to express: Something which has the db connection injected.

Can someone perhaps explain to me WHY we need to serialize a closure?

The reason for me to create this was that the "Node creation" test has a test case in which an exception is thrown. The test checks then if the watchdog contains the expected exception.
Unfortunately (on Windows / or even just within my installation) there's a closure in the backtrace of the exception. And this closure kills the whole exception handling because the backtrace can't be serialized.
Now instead to fix "just" the backtrace handling I decided to go for a more "general" solution.

peter: Try looking at Symfony's FlattenException class. It's a bit odd, but I think it's also addressing a similar issue in a less language-hostile way. :-)

Or, really, why are we serializing an entire backtrace...?

There's so much here that doesn't make sense to me.

The real problem here is #1158322: Add backtrace to all errors IMHO, that's the reason this happens in the first place.

While it makes sense to prevent it for other cases, fixing the other issue is IMHO more important so that we never try to serialize a whole backtrace in the first place.

#6: core-serializable-closure-1872690-6.patch queued for re-testing.

Duplicate of #2481349: Prevent the use of placeholders that cannot be converted into strings when creating logs