Serializing Closures
| From: | Nate Gordon | Date: | Wed, 31 Mar 2010 23:23:33 +0000 |
| Subject: | Serializing Closures | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-47699@lists.php.net to get a copy of this message | ||
Firstly, I'm not here to debate the merits or the how-to of serializing
closures. I'm here to address the current usability issues with how it is
prevented. The short background of what I'm doing is serializing backtraces
when errors occur so that I can better diagnose bugs my clients report. But
when a closure is passed as a function parameter somewhere in the call tree,
things just flat out exlode with the error:
Fatal error: Exception thrown without a stack frame in Unknown on line *0*
I've gotten around the problem in the short term by catching the exception
from the serialization, but then I loose my backtrace. It seems unfortunate
that I need to clean my backtrace before serializing it. The error that you
get when you try to serialize a Closure right now is:
Exception: Serialization of 'Closure' is not allowed in ....php on line *13*
While I'm perfectly fine having closures not serialize, having a closure
buried in an array or object and having that error out seems like a bad
thing as well. This gets even worse when trying to do this from within an
error handler, you lose all context of the error since throwing
exceptions/errors from within the error handler causes all sorts of bad
things to happen (Exception thrown without stack frame errors). I certainly
wasn't expecting serialize to be the thing that was causing the issue.
Thus, would it be possible to degrade this from something as severe as an
exception to being a simple warning, or just silently ignoring it and
continuing with the serialization? I would compare this to resource handles
for mysql connections and the like. Those are silently ignored.
I'm open to thoughts, comments, and suggestions and would be willing to
write a patch to make whatever changes are agreed upon.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does it
really go down?
<esc>:wq<CR>