FAQ

On Sat, May 21, 2016 at 8:16 PM, Rasmus Schultz wrote:
Alright, so forget my comparison with other languages.

My other points remain:

Presently, "throw new" is treated as though it was one statement.
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.

The construction site would only be relevant if "throw new" was in
deed a single statement.

Recording the actual throw site is clearly the goal - the current
implementation is betting on "throw" and "new" happening at the same
site, which is merely circumstance.

Ideally, an Exception should collect another stack trace for each
successive throw, which would enable you to trace not only the
original site, but the flow through any exception-handlers that might
have re-thrown the same Exception.

As is, there is no information collected on throw, and thereby no
evidence or record of possible re-throws - on top of the fact that you
may be collecting and looking at bogus stack-traces from factory
methods or exception mappers.

On Fri, May 20, 2016 at 11:06 AM, Rowan Collins wrote:
On 20/05/2016 08:22, Niklas Keller wrote:

2016-05-20 4:13 GMT+02:00 Jesse Schalken <me@jesseschalken.com>:
The top frame is the construction (get_error) and the site of the throw
(do_throw) doesn't appear in the stack at all.
The comparison with JavaScript isn't a good one, since you can throw
everything in JS. If they didn't provide the stack trace upon throw, you
would not have a stack trace at all if you throw a plain string.

That explanation justifies completely the opposite behaviour to what Jesse
described.

According to MDN [1] the "stack" property is completley unstandardised, and
some engines may indeed populate it on throw, but there's no hint on that
page that they'll attach it to anything not constructed as an Error.

So it's not a great comparison for either side (note that it was originally
brought up by Rasmus as an example where it *does* come from the throw site)
because the language doesn't actually guarantee you a stack trace at all.

[1]
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/stack

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
Hi.

I explained that in my article detailing Exceptions from internal ,
http://jpauli.github.io/2015/04/09/exceptional-php.html

I admit it would be more logical to collect the trace in the
ZEND_THROW Opcode instead of in the create_handler of the Exception
class.

That would break backtraces, but we already broke them in PHP 7.0
So we could think about it for a 8.0 ideally , or a 7.1 ; I'm not
sure. Anyway, that needs more debate ;-)



Julien.Pauli

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 14 of 18 | next ›
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 19, '16 at 11:14a
activeMay 24, '16 at 6:53p
posts18
users9
websitephp.net

People

Translate

site design / logo © 2019 Grokbase