[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Wrong stack line numbering on error()
- From: Francisco Olarte <folarte@...>
- Date: Mon, 21 Aug 2023 10:24:43 +0200
Hi Jonathan:
On Mon, 21 Aug 2023 at 09:42, Jonathan Goble <jcgoble3@gmail.com> wrote:
> On Mon, Aug 21, 2023, 03:05 Francisco Olarte <folarte@peoplecall.com> wrote:
>> I would try to solve the ambiguity by doc-patching anyway, although
>> defining the execution line is complex ( in things like loops when
>> looping etc.. ). I am used to that and do not thing the extra
>> bug-surface introduced by the detailed accounting is worthwile.
> Perhaps the best docs patch is to simply state the nature of the ambiguity. Something like, "For a statement spanning more than one line, the precise line reported could be the line on which the statement begins, the line on which it ends, or any line in between, regardless of which specific part of the statement is actually executing."
That is good for "simple" statements, I was thinking on compound
statements, like FOR/WHILE loops which have an executable part (
FUNCTIONs lines are not that executable in lua ). I have not looked at
the bytecode, but many languages implement the executable part of a
FOR loop in unusual places ( like at the END ). But this can be solved
by saying it ( execution of the loop can be reported at the FOR site
or at the END site, and reporting it all in the FOR is not that
complex, when doing the END you know where your corresponding FOR is (
capitals mine for "clarification" ) ).
> That would prevent the confusion raised here without increasing the bug surface or constraining future changes to the language, including in bugfix releases.
In fact current one is the full freedom version. Doc says
"currentline: the current line where the given function is executing".
"current line" only appears there in the doc, and the 5 other
occurrences of currentline do not refine it. ( I find that correct
enough, I treat this info as "accurate enough to build a stack trace"
). The problem also vanishes disallowing multiline statementes, after
all a call a(a(a(a(a(a(a(a(a(a(a(a(a(a(1))))))))))))) will always be
difficult to debug, and I would not expect s/a(/a(\n/ to make it clear
magically.
Francisco Olarte.