Re: Serializing Closures

On Wed, Mar 31, 2010 at 10:25 PM, Stanislav Malyshev <stas@zend.com> wrote: > 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>