Re: Stop Exceptions capturing object references for trace arguments
| From: | Niklas Keller | Date: | Sun, 13 Aug 2017 14:31:26 +0000 |
| Subject: | Re: Stop Exceptions capturing object references for trace arguments | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100198@lists.php.net to get a copy of this message | ||
2017-08-12 17:54 GMT+02:00 Stanislav Malyshev <smalyshev@gmail.com>:
> Hi!
>
> > My only concern is if anyone is using this data for anything other than
> > debugging - e.g. if they were somehow extracting extra context about the
> > exception by traversing the backtrace to a particular point and grabbing
> > the arguments. That feels like a horrible hack to me, but that doesn't
> > mean someone isn't relying on it.
>
> Sure, that's why I propose to keep the option. If you use the horrible
> hack, I think it wouldn't be too much to ask to set an INI variable.
> Since it's rather local, it can be INI_ALL so you could do it in the
> script even.
>
> > An interesting side effect of an ini setting, though, is that it could
> > in turn be made to raise deprecation warnings at some point, whereas
> > just accessing the 'args' element of an array is pretty hard to detect.
> > So for instance, we could theoretically have: 7.3, add ini setting
> > defaulting to on; 7.4, change default to off and raise deprecation
> > notice if it's turned on; 8.0, remove feature, error if ini setting is
> > not set to on (ignore if set to off for smoother upgrades).
>
> Yep, sounds like a plan. Not sure if we need to drop it for 8.0 even,
> but we can vote on that. Anybody to make an RFC for this? :)
>
If it's explicitly needed, someone could still just call
debug_backtrace() and manually store the args in the exception
constructor, no?
Would the args still be available in the stringified version? Because
they're quite useful for debugging there.
Regards, Niklas