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.
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).
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.
On 1 December 2025 10:36:51 GMT, Derick Rethans [<derick@php.net>](mailto: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.`