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>
