Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:48757
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain quis.cx from 85.223.64.56 cause and error)
Message-ID: <4C1502D9.6000305@quis.cx>
Date: Sun, 13 Jun 2010 18:10:01 +0200
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Kalle Sommer Nielsen <kalle@php.net>
CC: internals@lists.php.net
References: <4C14BE21.2040401@quis.cx> <AANLkTil137QTc-Uyn58PRH7-JW6oA5WLqQao_uq_Vf-c@mail.gmail.com>
In-Reply-To: <AANLkTil137QTc-Uyn58PRH7-JW6oA5WLqQao_uq_Vf-c@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] #45351: Exception::getTrace() should return 'object'
  array-element
From: jille@quis.cx (Jille Timmermans)

Hello Kalle,

First of all, thanks for yor feedback!

Kalle Sommer Nielsen schreef:
> Hello Jille
> 
> 2010/6/13 Jille Timmermans <jille@quis.cx>:
>> http://bugs.php.net/45351
>>
>> I have attached a patch to the feature request. IIRC I should just ask
>> here whether someone is willing to commit it. So, anyone willing to help
>> me? :)
> 
> The patch is incorrect (according to what the user requests, and for
> consistency with debug_backtrace()). What the patch should do is to:
> 
> 1) Add a new parameter to the arginfo, so reflection can pick this new
> parameter up, named provide_object
I succeeded with that part.
> 2) Alter the implementation of Exception::getTrace(),
> ::getTraceAsString() and possibly also ::__toString() so it sends to
> the proper parameters to the function that builds the trace
> array/string
The trace is generated at the construction of the exception; because we
don't know whether getTrace() will get called with provide_object we
need to save it anyway.
I have tried to alter ::getTrace() to remove the 'object' key from the
stack frames if provide_object was given as false. Unfortunately I
didn't succeed there. (I don't know much of the internals; and after
playing around calling 'random' functies I decided the patch I would
create wouldn't be perfect anyway.) So I trashed the parts I was
uncertain of and built the following diff:
  http://junk.quis.cx/XlUKZqbe/zend_exceptions.diff

If someone has time and is willing to finish the patch, please go for
it. (Or instructing me how to do it; but I assume that will take more time.)

-- Jille
> 
> If you simply change the 0 to 1, then it will be forced every time,
> and without looking closer to the implementation i can imagine it
> could cause some unwanted overheat if its not used, or lookup time.
>