Re: [PHP-DEV] Exception::getLine()

+1 There is use case - exception without backtrace, used to global return. Example REST API throw new RedirectExeception('/url', 302); // creating in backtrace is overhead -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Exception::getLine()

2016-05-24 17:32 GMT+02:00 Rasmus Schultz : > > it would be more logical to collect the trace in the ZEND_THROW Opcode > instead of in the create_handler of the Exception class > > I've been pondering a means of doing this with relatively few BC issues. > > There are four

Re: [PHP-DEV] Exception::getLine()

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

Re: [PHP-DEV] Exception::getLine()

> it would be more logical to collect the trace in the ZEND_THROW Opcode > instead of in the create_handler of the Exception class I've been pondering a means of doing this with relatively few BC issues. There are four use-cases right now: 1. Direct: throw new Exception() 2. Indirect: throw

Re: [PHP-DEV] Exception::getLine()

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

Re: [PHP-DEV] Exception::getLine()

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

Re: [PHP-DEV] Exception::getLine()

On 20/05/2016 08:22, Niklas Keller wrote: 2016-05-20 4:13 GMT+02:00 Jesse Schalken : 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

Re: [PHP-DEV] Exception::getLine()

2016-05-20 4:13 GMT+02:00 Jesse Schalken : > > 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

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

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

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.

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

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,

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

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

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()

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

[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