Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64581
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.178 as permitted sender)
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Stas Malyshev" <smalyshev@sugarcrm.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <CACYoSNCr30Fg+oBASGmLYLk+ziXQy990mvZbLNUe8viNhZTdxQ@mail.gmail.com> <50E742A7.9010909@sugarcrm.com> <op.wqglnxjnqezz7x@jachym-pc> <50E8A99F.5000900@sugarcrm.com> <op.wqgotfcfqezz7x@jachym-pc> <50E8BA82.5000700@sugarcrm.com> <op.wqgpo6idqezz7x@jachym-pc> <50E8BC3E.4030705@sugarcrm.com>
Date: Sun, 06 Jan 2013 01:08:34 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.wqgqoksjqezz7x@jachym-pc>
In-Reply-To: <50E8BC3E.4030705@sugarcrm.com>
User-Agent: Opera Mail/12.11 (Win32)
Subject: Re: [PHP-DEV] How to get a PHP bug fixed?
From: enumag@gmail.com (=?utf-8?B?SsOhY2h5bSBUb3XFoWVr?=)

I agree with you that the parameters would be good. There should also be the limit parameter (same as for debug_backtrace). However I'm afraid I'm not that much familiar with C to actually write it.

It's true that in 'args' there theoretically may not be any object. But as you are surely aware, the probability of that is pretty much zero in a real PHP application. Unless it does not use OOP of course, but in that case the 'object' field would also be empty.

That means it would be good to add the parameters to Exception::getTrace(), but as I'm unable to do so there won't be anything wrong with just adding the 'object' for the timebeeing, don't you think? It would be very helpful for those who use some fancy debugger (see http://blog.juzna.cz/2011/07/tuning-error-reporting-in-php/).


Dne Sun, 06 Jan 2013 00:50:22 +0100 Stas Malyshev <smalyshev@sugarcrm.com> napsal(a):

> Hi!
>
>> I don't understand. There already IS the 'args' field where huge
>> objects also can be (and very often are). The new 'object' field
>> does not make any difference in this regard.
>
> It adds another place where huge objects can be - and unlike args, it is
> guaranteed to be an object, and those tend to be big. So chances to blow
> up the memory with this function become higher. That's why other
> functions gained parameters to amend this situation some time ago, this
> one would be good to add it too.