On 24/05/2016 16:32, Rasmus Schultz wrote:
The second use-case (indirect throw, factory) and third use-case
(re-throwing) are both broken as-is - in either case, it isn't
reporting the correct stack-trace now. This change corrects those
cases. Even if that's a minor BC break, it corrects an error.
I'm still not convinced that re-throwing should automatically generate a
new stack trace.
To repeat my previous question, why should the two blocks below produce
different backtraces?
# A:
try {
throw new FooException;
}
catch ( BarException $e ) {
// FooException doesn't match the constraint, so bubbles up
}
# B:
try {
throw new FooException;
}
catch ( Exception $e ) {
if ( ! $e instanceOf BarException ) {
// FooException doesn't match the constraint, so is re-thrown
throw $e;
}
}
Since no actual changes happened to $e in block B (and exceptions should
normally be immutable in practice, I think), what information is gained
by knowing that a block caught it, examined it, and decided it could do
nothing with it? And if that information is valuable, why is not also
valuable when the check is implicit in the specification of the catch
clause?
In my opinion, it would be reasonable to attach the stack trace *the
first time* an exception was thrown. This fixes your main problem,
indirect / factory construction, and would be relatively simple to
implement - when throwing the exception, check if the stack trace has
already been added; if not, add it.
Would a change like this require an RFC (and a vote) or is it arguably
a bug? (I'm guessing this change is too substantial to be considered a
"bug fix"?)
In my opinion, it's substantial behaviour change, and would definitely
require an RFC, particularly if the default behaviour of one or more
methods would change, so that unchanged PHP code gave different results.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
