Adds possibility to include called object in exception backtrace

[marc-mabe]

This 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.

Open questions:

• Does this need an RFC?
• Could this be considered for a PHP patch release?
• Should zend.exception_provide_object be enabled by default in run-tests.php (similar to zend.exception_ignore_args=0)

[mvorisek]

I am personally interested in this to be able to inspect the called Closures. If this PR will allow this, please add a test like https://3v4l.org/YqFcG (my usecase it is to able to extract $this and use variable in catch clause of the called closure).

[marc-mabe]

@mvorisek I have updated the testcase to include a closure as well. Variables use'd are not part of the trace as the closure object points to the object the closure is bind to.

[arnaud-lb]

One thing to note is that enabling zend.exception_provide_object can change the behavior of programs using destructors, as it will increase the refcount of the objects, and therefore delay destructor calls.

[marc-mabe]

One thing to note is that enabling zend.exception_provide_object can change the behavior of programs using destructors, as it will increase the refcount of the objects, and therefore delay destructor calls.

True, and the same is true for objects referenced in arguments. I have added a note to zend.exception_ignore_args and zend.exception_provide_object.

[iluuu1994]

Does this need an RFC?

This needs a discussion on the internals list at least. If somebody objects, it will need an RFC.

Could this be considered for a PHP patch release?

New features should not target patches, see https://wiki.php.net/rfc/release_cycle_update#disallow_new_features_in_release_candidates_and_bug_fix_releases.

Should zend.exception_provide_object be enabled by default in run-tests.php (similar to zend.exception_ignore_args=0)

IMO, that part would definitely require an RFC.