Re: Stop Exceptions capturing object references for trace arguments
| From: | Rowan Collins | Date: | Sat, 12 Aug 2017 14:37:08 +0000 |
| Subject: | Re: Stop Exceptions capturing object references for trace arguments | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-100193@lists.php.net to get a copy of this message | ||
On 12/08/2017 04:25, Stanislav Malyshev wrote:
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. 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). Regards, -- Rowan Collins [IMSoP]The "args" part of this contains full object references to anything that happens to have been a function argument in the stack, and causes two problems:I think it makes sense to make exception not to collect args. In fact, I think this may also be one of rare cases where new ini setting would be appropriate, where the default could be the old way (at least for now, for BC), and recommended production setting would be off.