Re: #45351: Exception::getTrace() should return 'object' array-element
| From: | Jille Timmermans | Date: | Sun, 13 Jun 2010 16:10:01 +0000 |
| Subject: | Re: #45351: Exception::getTrace() should return 'object' array-element | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-48757@lists.php.net to get a copy of this message | ||
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.
>