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
Hi!
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:
Hmm, serializing backtrace may be tricky - a lot of stuff there might be
unserializable. In general, serializing is not meant to be used for
debugging. You might have better luck with debug printing functions.
But nevertheless this:
Fatal error: Exception thrown without a stack frame in Unknown on line 0
doesn't look good. It'd be nice if you made a short code example and
submitted a bug about it. I think reporting there might be improved.
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.
Maybe it should be null+warning?
Stanislav Malyshev, Zend Software Architect
stas@zend.com http://www.zend.com/
(408)253-8829 MSN: stas@zend.com
Hi!
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:Hmm, serializing backtrace may be tricky - a lot of stuff there might be
unserializable. In general, serializing is not meant to be used for
debugging. You might have better luck with debug printing functions.
But nevertheless this:Fatal error: Exception thrown without a stack frame in Unknown on line 0
doesn't look good. It'd be nice if you made a short code example and
submitted a bug about it. I think reporting there might be improved.
I'm starting to agree with you on serializing a backtrace. custom encoding,
or captured text of debug_print_backtrace would probably be better to remove
complex arguments. We have a nice backtrace browser that we use that draws
the backtrace with the code from the line it was called from. Its handy for
reviewing what went wrong from a client perspective, but it is hard to
capture the entire state of a running app to store in a database. I've
submitted a bug for the other part of this (nested exceptions), and maybe I
will even submit a patch, time pending.
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.Maybe it should be null+warning?
I'm leaning that way, but I'm biased towards making serialization more fool
proof.
--
-Nathan Gordon
If the database server goes down and there is no code to hear it, does it
really go down?
<esc>:wq<CR