2017-08-12 17:54 GMT+02:00 Stanislav Malyshev <smalys...@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
