Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:69515
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.48 as permitted sender)
Message-ID: <5253C1A4.8070303@gmail.com>
Date: Tue, 08 Oct 2013 09:26:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: internals@lists.php.net
References: <52532F2C.2010704@gmail.com> <52533D9D.5050203@wikimedia.org>
In-Reply-To: <52533D9D.5050203@wikimedia.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Exceptions, stack traces, and serialization
From: rowan.collins@gmail.com (Rowan Collins)

Tim Starling wrote (on 08/10/2013):
> 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

The problem with that is that you can't control what exceptions are 
thrown by third-party libraries (or even some of the newer core 
extensions), or force them to inherit from your base. If they turn off 
the argument capture, the information will already be unavailable when 
you catch the exception, and if they turn it on, you will still need a 
function to strip it after the fact.

Obviously you can discard the third-party exception and throw your own, 
but normally you would chain yours onto it, retaining whatever 
information it originally contained.

-- 
Rowan Collins
[IMSoP]