Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47699
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:date:message-id:subject:from:to:content-type;
        b=Onx7S+UOtcdXpHA+QbO+NIwnG5B17I2FX5pHyuWmlBIX7S3FY2PcgN9iNkILrT88Ci
         BcQC1xIsncwqvGpc7mAF1+lceueqMtvDA9GRSY7+8XJdCs+lBVsYTnK0sbSuPmGGONqS
         OPAoSOcJQz8QZf19O5Wtf5B8M5gJ+Trqh1juc=
MIME-Version: 1.0
Date: Wed, 31 Mar 2010 18:23:33 -0500
Message-ID: <m2tffa0ace81003311623he2a2485axf6ada2602f14ade9@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016e6d99c2ce7cbe2048321084d
Subject: Serializing Closures
From: nlgordon@gmail.com (Nate Gordon)

--0016e6d99c2ce7cbe2048321084d
Content-Type: text/plain; charset=UTF-8

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>

--0016e6d99c2ce7cbe2048321084d--