Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Possibility to include called object in exception backtrace »

Possibility to include called object in exception backtrace

php.internals

Marc

276 days ago
Hi all, I have opened a simple PR to add the possibility to include called object in exception backtrace. https://github.com/php/php-src/pull/20599 This needs a discussion here to see if there are objections. About the patch: The patch adds the ability to populate the called |object| into exception backtraces. Previously, only |debug_backtrace()| could include the called object in its frames, but |Exception::getTrace()| could not. This change aligns |Exception::getTrace()| with |debug_backtrace()| by introducing a new INI directive: |zend.exception_provide_object (boolean)| This directive is analogous to the existing |zend.exception_ignore_args| option, but controls whether the |object| field is included in exception backtraces. *Behavior:* * When zend.exception_provide_object = 0 (default), behavior is unchanged: exception traces do not contain the object. * When zend.exception_provide_object = 1, exception backtrace includes the called |object| (where applicable). *Defaults:* * No configuration value provided: |zend.exception_provide_object = Off| * |php.ini-production|: |zend.exception_provide_object = Off| * |php.ini-development|: |zend.exception_provide_object = On| *Use cases and considerations:* This feature is primarily intended for development and debugging. Provides richer diagnostic information by exposing the actual object on which methods were invoked. Can help track down state-dependent bugs that depend on specific object properties. However, it is not recommended for production environments, because: * It may expose sensitive data held on objects in logs or error output. * It can increase memory usage and the size of collected traces. For production systems, |zend.exception_provide_object| should remain disabled. Additionally, I added a note to zend.exception_ignore_args and zend.exception_provide_object as this increases the refcount of the objects, and therefore may delay object destruction. Marc

Derick Rethans

274 days ago
On Sat, 29 Nov 2025, Marc B. wrote:
> I have opened a simple PR to add the possibility to include called > object in exception backtrace. > > https://github.com/php/php-src/pull/20599 > > This needs a discussion here to see if there are objections. > > About the patch: > > The patch adds the ability to populate the called |object| into > exception backtraces.
I do this in Xdebug (as part of https://bugs.xdebug.org/1562) and it's causing some issues with fframeworks/applications that rely on destructors being called at a specific time, or in a specific order: https://bugs.xdebug.org/2222 The Xdebug situation is probably a little worse, as I keep that last 8 exception traces *too*, but I am sure this is going to trip up people.
> > Previously, only |debug_backtrace()| could include the called object > in its frames, but |Exception::getTrace()| could not. This change > aligns |Exception::getTrace()| with |debug_backtrace()| by introducing > a new INI directive: > > |zend.exception_provide_object (boolean)|
I don't think that adding an INI setting (again) is a good idea. If you want to make this configurable, it should be an option on Exception::getTrace() — INI settings make applications less portable (even though this is a debugging option). cheers, Derick

Rowan Tommins [IMSoP]

274 days ago
On 1 December 2025 10:36:51 GMT, Derick Rethans <derick@php.net> wrote:
>I don't think that adding an INI setting (again) is a good idea. If you >want to make this configurable, it should be an option on >Exception::getTrace() — INI settings make applications less portable >(even though this is a debugging option).
A parameter on the getter would mean every exception has to capture the references just in case they're used, which would definitely be a bad idea. If I remember rightly, the existing INI setting for capturing parameters was added precisely so that users could turn *off* collection in production builds. The same reasoning applies to other debugging settings, like skipping evaluation of assertions rather than silently discarding their results. Regards, Rowan Tommins [IMSoP]

Marc

273 days ago
Hi Derick, On 01.12.25 12:44, Rowan Tommins [IMSoP] wrote:
> On 1 December 2025 10:36:51 GMT, Derick Rethans<derick@php.net> wrote: >> I don't think that adding an INI setting (again) is a good idea. If you >> want to make this configurable, it should be an option on >> Exception::getTrace() — INI settings make applications less portable >> (even though this is a debugging option). > > A parameter on the getter would mean every exception has to capture the references just in case they're used, which would definitely be a bad idea. > > If I remember rightly, the existing INI setting for capturing parameters was added precisely so that users could turn *off* collection in production builds. > > The same reasoning applies to other debugging settings, like skipping evaluation of assertions rather than silently discarding their results.
As Rowan already mentioned, adding a parameter to `getTrace()` would require every exception object to keep a reference of the called object just to make it retrievable if requested. Configuring it as INI option - it can, and should, be turned off on production environments. Also, the INI option `|zend.exception_provide_object` would be in line `||zend.exception_ignore_args` making it's use consistent with already existing behavior.|
> Regards, > > Rowan Tommins > [IMSoP]
Regards, Marc

Marc

261 days ago
Hi all, this is a reminder If there are still any objections about this PR please speak up. Else, I would kindly ask for merge without RFC. Thanks Marc On 29.11.25 08:14, Marc B. wrote: