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
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
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]
Hi Derick,
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
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
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