[PHP-DEV] Exception::getLine()
Does this work as intended?
function create_exception() {
return new RuntimeException(); // line 2
}
try {
throw create_exception(); // line 6
} catch (Exception $e) {
var_dump($e); // => 2
}
I would have expected Exception::getLine() to return 6 in this case -
the line where the exception was thrown.
I know that I can dig in via e.g.
Exception::getStackTrace()[0]["line"] and pull the relevant
line-number myself, but I'm wondering why the line-number 2 is
relevant, important or interesting at all?
It's not uncommon to have e.g. static factory methods inside the
exception itself, which would cause the exception instance to report
the line-number of the new-statement inside the factory constructor,
which has no particular importance or relevance for any purpose, as
far as I can figure.
Apparently this has been reported as a bug before:
https://bugs.php.net/bug.php?id=53882
There was talk of a fix in the comments, but it looks like this issue
went stale and was closed without any further explanation?
The documentation is also a little ambiguous on this point:
http://php.net/manual/en/exception.getline.php
At the top of the page, it says "Gets the line in which the exception
occurred", which isn't correct. (The rest of the page correctly says
"the line number where the exception was created")
Would it adversely affect anything to fix this?
It's technically a BC break, I guess.
Perhaps adding a dedicated getLineThrown() method would be better with
regards to BC?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
On 19.05.2016 13:14, Rasmus Schultz wrote:
> I know that I can dig in via e.g.
> Exception::getStackTrace()[0]["line"] and pull the relevant
> line-number myself, but I'm wondering why the line-number 2 is
> relevant, important or interesting at all?
If you are rethrowing exceptions inside the catch bloc:
for ($code = 0; $code < 2; $code++) {
try {
throw new Exception('Message '.$code, $code);
}
catch (\Exception $e) {
if ($e->getCode() > 0) {
throw $e;
}
}
}
Inside the catch bloc I check whether the Exception code is one that can
be handled at that place (code = 0), if not I rethrow the exception. If
the line property would refer to the place where the exception was
thrown I'd lose information in that case.
Tim
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
Am 19.05.2016 um 13:14 schrieb Rasmus Schultz: > Does this work as intended? According to https://bugs.php.net/bug.php?id=64910 it does :-( -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
Sebastian Bergmann schrieb am Do., 19. Mai 2016 14:12: > Am 19.05.2016 um 13:14 schrieb Rasmus Schultz: > > Does this work as intended? > > According to https://bugs.php.net/bug.php?id=64910 it does :-( > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php Resending to complete list: Yes, this is intended. Exceptions in PHP are always populated upon creation. Please note the already mentioned issues with rethrowing and also, that some exceptions might not get thrown at all, e.g. because of the use of promises.
[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-05-19
Results for project PHP master, build date 2016-05-19 06:28:59+03:00 commit: 88196e9 previous commit:14023d3 revision date: 2016-05-18 15:06:49+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB mem:128 GB os: CentOS 7.1 kernel: Linux 3.10.0-229.4.2.el7.x86_64 Baseline results were generated using release php-7.0.0, with hash 60fffd2 from 2015-12-01 04:16:47+00:00 --- benchmark relative change since change since current rev run std_dev* last run baseline with PGO --- :-| Wordpress 4.2.2 cgi -T1 0.13% -0.12% 1.16% 6.88% :-| Drupal 7.36 cgi -T1 0.12% 0.14% 0.22% 4.57% :-| MediaWiki 1.23.9 cgi -T5000 0.09% -0.66% 0.61% 3.23% :-) bench.php cgi -T100 0.03% 1.99% 28.31% -2.99% :-( micro_bench.php cgi -T10 0.02% -1.20% 4.61% 3.43% :-( mandelbrot.php cgi -T100 0.11% -1.04% 31.19% 4.56% --- * Relative Standard Deviation (Standard Deviation/Average) If this is not displayed properly please visit our results page here: http://languagesperformance.intel.com/ugly-benchmark-results-for-php-master-2016-05-19/ Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in fetches/second while all others are measured in seconds. More details on measurements methodology at: https://01.org/lp/documentation/php-environment-setup. Subject Label Legend: Attributes are determined based on the performance evolution of the workloads compared to the previous measurement iteration. NEUTRAL: performance did not change by more than 1% for any workload GOOD: performance improved by more than 1% for at least one workload and there is no regression greater than 1% BAD: performance dropped by more than 1% for at least one workload and there is no improvement greater than 1% UGLY: performance improved by more than 1% for at least one workload and also dropped by more than 1% for at least one workload Our lab does a nightly source pull and build of the PHP project and measures performance changes against the previous stable version and the previous nightly measurement. This is provided as a service to the community so that quality issues with current hardware can be identified quickly. Intel technologies' features and benefits depend on system configuration and may require enabled hardware, software or service activation. Performance varies depending on system configuration. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
> Exceptions in PHP are always populated upon creation Wow. Well, I've always wondered why the throw site wasn't in the stack trace - this explains that. This is inconsistent with at least JavaScript and C#, where the stack trace is populated at the throw site. (Probably others?) That doesn't really make any sense to me, for a number of reasons. First, who cares where the Exception was constructed? That has no relevance, and it's often a factory method or in some cases a more complex facility, such as the one in Doctrine DBAL that maps PDO error info to an Exception. You will miss the actual throw site - unless it happens to be the same site as where the constructor was invoked, but there's no guarantee of that. When exceptions get re-thrown, there is no trace of the actual site from where the unhandled Exception was thrown - you're lugging around a stack trace that doesn't actually have the current stack. Technically, every throw is a new exception "flow" - even if you're recycling the Exception instance, it's the throw statement that starts the unique stack unwind from the throw site; it's where the action happens. What's important then, is the throw statement, not the object, since the site where the object happens to get created has no bearing on the stack at the time when the exception gets thrown or re-thrown. In other words, throw new Exception() only happens to work most of the time because the throw and new statements happen to be issued at the same site. This is wonky. Can we fix it? On Thu, May 19, 2016 at 3:05 PM, Niklas Keller wrote: > Sebastian Bergmann schrieb am Do., 19. Mai 2016 14:12: > >> Am 19.05.2016 um 13:14 schrieb Rasmus Schultz: >> > Does this work as intended? >> >> According to https://bugs.php.net/bug.php?id=64910 it does :-( >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php > > > Resending to complete list: > > Yes, this is intended. Exceptions in PHP are always populated upon creation. > > Please note the already mentioned issues with rethrowing and also, that > some exceptions might not get thrown at all, e.g. because of the use of > promises. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
On 19/05/2016 19:35, Rasmus Schultz wrote:
Technically, every throw is a new exception "flow" - even if you're > recycling the Exception instance, it's the throw statement that >
starts the unique stack unwind from the throw site; it's where the >
action happens.
That's one interpretation, but it doesn't really hold up in all cases.
Consider a catch statement that needs to filter more granularly than the
class name; since you already mentioned PDO, I'll make an example with that:
catch ( PDOException $e ) {
if ( substr($e->getCode(), 0, 2) === '08' ) {
$this->reconnect();
} else {
throw $e;
}
}
Of what value to a subsequent catch statement is the trace of that throw
statement? And why does that "start a new exception flow", but if PDO
threw different sub-classes, you could let one flow through unmodified
by tightening the catch statement?
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
On Thu, May 19, 2016 at 1:47 PM, Rowan Collins
wrote:
> On 19/05/2016 19:35, Rasmus Schultz wrote:
>
>> Technically, every throw is a new exception "flow" - even if you're >
>> recycling the Exception instance, it's the throw statement that >
>>
> starts the unique stack unwind from the throw site; it's where the >
> action happens.
>
> That's one interpretation, but it doesn't really hold up in all cases.
> Consider a catch statement that needs to filter more granularly than the
> class name; since you already mentioned PDO, I'll make an example with that:
>
> catch ( PDOException $e ) {
> if ( substr($e->getCode(), 0, 2) === '08' ) {
> $this->reconnect();
> } else {
> throw $e;
> }
> }
>
> Of what value to a subsequent catch statement is the trace of that throw
> statement? And why does that "start a new exception flow", but if PDO threw
> different sub-classes, you could let one flow through unmodified by
> tightening the catch statement?
>
True, but if you instead of throwing the same exception, threw a new one,
you could capture both stacks. But you can never get the stack from the
throw point of something created elsewhere.
catch ( PDOException $e ) {
if ( substr($e->getCode(), 0, 2) === '08' ) {
$this->reconnect();
} else {
throw new PDOException($e->getMessage(), $e->getCode(), $e);
}
}
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Exception::getLine()
> True, but if you instead of throwing the same exception, threw a new one, you
> could capture both stacks. But you can never get the stack from the throw
> point of something created elsewhere.
Precisely.
I think there are good reasons why other languages collect the
stack-trace on throw.
Collecting the stack trace at construction would be correct if "throw
new" was literally one statement - if the only time you could throw
was at creation.
That's not the case. We have deferred throws and factory methods for
exceptions, and we have re-throws, so collecting the stack-trace at
construction time doesn't work.
Of course, fixing this would require a BC break, and nobody wants to
even entertain the thought of those :-(
On Thu, May 19, 2016 at 10:30 PM, Ryan Pallas wrote:
> On Thu, May 19, 2016 at 1:47 PM, Rowan Collins
> wrote:
>
>> On 19/05/2016 19:35, Rasmus Schultz wrote:
>>
>>> Technically, every throw is a new exception "flow" - even if you're >
>>> recycling the Exception instance, it's the throw statement that >
>>>
>> starts the unique stack unwind from the throw site; it's where the >
>> action happens.
>>
>> That's one interpretation, but it doesn't really hold up in all cases.
>> Consider a catch statement that needs to filter more granularly than the
>> class name; since you already mentioned PDO, I'll make an example with that:
>>
>> catch ( PDOException $e ) {
>> if ( substr($e->getCode(), 0, 2) === '08' ) {
>> $this->reconnect();
>> } else {
>> throw $e;
>> }
>> }
>>
>> Of what value to a subsequent catch statement is the trace of that throw
>> statement? And why does that "start a new exception flow", but if PDO threw
>> different sub-classes, you could let one flow through unmodified by
>> tightening the catch statement?
>>
>
> True, but if you instead of throwing the same exception, threw a new one,
> you could capture both stacks. But you can never get the stack from the
> throw point of something created elsewhere.
>
> catch ( PDOException $e ) {
> if ( substr($e->getCode(), 0, 2) === '08' ) {
> $this->reconnect();
> } else {
> throw new PDOException($e->getMessage(), $e->getCode(), $e);
> }
> }
>
>
>
>> Regards,
>> --
>> Rowan Collins
>> [IMSoP]
>>
>>
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
On 19/05/2016 21:30, Ryan Pallas wrote: Of what value to a subsequent catch statement is the trace of that throw statement? And why does that "start a new exception flow", but if PDO threw different sub-classes, you could let one flow through unmodified by tightening the catch statement? True, but if you instead of throwing the same exception, threw a new one, you could capture both stacks. The same could be said of the current behaviour: throw new PDOException($e->getMessage(), $e->getCode(), $e); Since this contains both "throw" and "new", it's guaranteed a new stack trace in either convention. So the question remains which is the *more likely* desired behaviour if you *don't* re-wrap it, and I honestly don't know the answer. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exception::getLine()
On Fri, May 20, 2016 at 4:35 AM, Rasmus Schultz wrote:
> This is inconsistent with at least JavaScript and C#, where the stack
> trace is populated at the throw site. (Probably others?)
>
I'm not sure about C#, but in JavaScript (Node.js):
function get_error() {
return new Error('my error');
}
function do_throw(e) {
throw e;
}
try {
do_throw(get_error());
} catch (e) {
console.log(e.stack);
}
results in:
Error: my error
at get_error (/home/jesse/src/test.js:2:12)
at Object. (/home/jesse/src/test.js:10:14)
at Module._compile (module.js:413:34)
at Object.Module._extensions..js (module.js:422:10)
at Module.load (module.js:357:32)
at Function.Module._load (module.js:314:12)
at Function.Module.runMain (module.js:447:10)
at startup (node.js:146:18)
at node.js:404:3
The top frame is the construction (get_error) and the site of the throw
(do_throw) doesn't appear in the stack at all.
[PHP-DEV] [RFC][Vote] Typed Properties
Morning internals, Since we have our answer on nullable types, typed properties can now go to vote. https://wiki.php.net/rfc/typed-properties#vote Note that, support for nullability as RFC'd will be merged when the implementation for nullable_types is merged into master. Please participate. Cheers Joe
