Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93486
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.46 as permitted sender)
References: <CADqTB_jC-EZ5p+c=q0dmRgaYAkyRVbdNFNUQRGhfaS7GaOTR9g@mail.gmail.com>
 <72f547d6-5fcf-3cd2-960d-cb612a429e47@php.net>
 <CANUQDCiEDeCV3RAr0bg+=-PHPDYkk-cP-ih4TnTGUzz7SNakMw@mail.gmail.com>
 <CADqTB_j67-ocNaWm5sRHbC4vJF2t7WBWUqrEXu9-Kk_MSi4CgA@mail.gmail.com>
 <CAF1yvAQozS1qpCbBNdAJu4gT5LbOEUimv2W-nWtkaUTbVZFubA@mail.gmail.com>
 <CANUQDCjnEgJwT5zEb50sWA5=OeF-LRzPDu_1+-E70as2N10oXw@mail.gmail.com>
 <fb93f245-a5e6-53f7-9fee-deaebb847b78@gmail.com>
 <CADqTB_inxTXkg+mVGyBVsP1drDqsWfaLMKe00R=veBQT7ZKedQ@mail.gmail.com>
 <CAMUwpuR=ES4eWTofrAcfC434nFQOrAyp5cy-wVdAykVr3BwE-A@mail.gmail.com>
 <CADqTB_jXnLZx-F_-08+F1APoUTd_9C-Gt+vuc2GAk=xWeXFw=A@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Message-ID: <894687cd-38fa-da3d-2515-4df085091976@gmail.com>
Date: Tue, 24 May 2016 17:26:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_jXnLZx-F_-08+F1APoUTd_9C-Gt+vuc2GAk=xWeXFw=A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Exception::getLine()
From: rowan.collins@gmail.com (Rowan Collins)

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]