Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69512
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain wikimedia.org designates 208.80.152.186 as permitted sender)
Message-ID: <52533D9D.5050203@wikimedia.org>
Date: Tue, 08 Oct 2013 10:02:53 +1100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <52532F2C.2010704@gmail.com>
In-Reply-To: <52532F2C.2010704@gmail.com>
OpenPGP: id=BF976370
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Exceptions, stack traces, and serialization
From: tstarling@wikimedia.org (Tim Starling)

On 08/10/13 09:01, Rowan Collins wrote:
>
> (2) Don't capture arguments in the trace of an exception, similar to
> debug_backtrace with DEBUG_BACKTRACE_IGNORE_ARGS set. This would
> technically be a BC break, but I'm not sure how much real code would
> care. It's impossible to reconstruct details of the calls fully
> without the PROVIDE_OBJECT behaviour anyway.
>
> This would also have the advantage of making destructors fire more
> predictably - at the moment, an exception can bubble past a block of
> code with a deliberately scoped object (e.g. an RAII-style lock
> token), and if that object happens to be an argument within the
> Exception's trace, it survives until the Exception itself is
> destructed, because it has a reference inside the Exception's trace.
> Again, arguably you shouldn't be relying on this or keeping
> Exception objects around for long anyway, but it's kind of
> unexpected behaviour.

Is it possible to make the trace options be overridable by the
Exception subclass? That would provide a migration path for any code
that did rely on the args being available. And I think our app could
benefit from having closure objects available for logging, especially
if it is possible to get line numbers.

-- Tim Starling