>
> Would the args still be available in the stringified version? Because
>> they're quite useful for debugging there.
>>
>
> Hm, I guess we'd need to store the string representation (the class name,
> basically) somewhere so we could keep that. Doesn't seem like it ought to
> be too hard, unless t
On 13/08/2017 15:31, Niklas Keller wrote:
If it's explicitly needed, someone could still just call
`debug_backtrace()` and manually store the args in the exception
constructor, no?
That depends exactly how it's being used, but yes if you control the
throw site or Exception constructor you c
2017-08-12 17:54 GMT+02:00 Stanislav Malyshev :
> 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 argu
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
On 12/08/2017 04:25, Stanislav Malyshev wrote:
Hi!
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 al
Hi!
> 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 settin
