Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47727
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=RI2Nc/YFNqhaKNGgpNh7QUntmHnf0G0HxCk3QqcPpbKitop/UMoLB+T0Pqhf0tFC2t
         jL5wQ7OQedUAIh9zzZq68wVanESRH1q0OS1fJExDy/G89MzR9LkLwYHY3esVT5RAecwd
         u0wWALPrCFXZ2FDCbsbi6Jd3ihElQbrt78G48=
MIME-Version: 1.0
In-Reply-To: <4BB42028.1050007@zend.com>
References: <m2tffa0ace81003311623he2a2485axf6ada2602f14ade9@mail.gmail.com>
	 <4BB42028.1050007@zend.com>
Date: Thu, 1 Apr 2010 16:08:55 -0600
Message-ID: <y2qffa0ace81004011508m953731f1y92b929ee7d570deb@mail.gmail.com>
To: Stanislav Malyshev <stas@zend.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6d99bfed6bc840483341b76
Subject: Re: [PHP-DEV] Serializing Closures
From: nlgordon@gmail.com (Nate Gordon)

--0016e6d99bfed6bc840483341b76
Content-Type: text/plain; charset=UTF-8

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>

--0016e6d99bfed6bc840483341b76--