On 08/10/13 09:01, Rowan Collins wrote: > > (2) Don't capture arguments in the trace of an exception, similar to > debug_backtrace with DEBUG_BACKTRACE_IGNORE_ARGS set. This would > technically be a BC break, but I'm not sure how much real code would > care. It's impossible to reconstruct details of the calls fully > without the PROVIDE_OBJECT behaviour anyway. > > This would also have the advantage of making destructors fire more > predictably - at the moment, an exception can bubble past a block of > code with a deliberately scoped object (e.g. an RAII-style lock > token), and if that object happens to be an argument within the > Exception's trace, it survives until the Exception itself is > destructed, because it has a reference inside the Exception's trace. > Again, arguably you shouldn't be relying on this or keeping > Exception objects around for long anyway, but it's kind of > unexpected behaviour.
Is it possible to make the trace options be overridable by the Exception subclass? That would provide a migration path for any code that did rely on the args being available. And I think our app could benefit from having closure objects available for logging, especially if it is possible to get line numbers. -- Tim Starling -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
