andrew/akbasic
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Stop an armed TRAP from swallowing parse errors whole

Browse Source 
A program with TRAP set and a line that would not parse printed nothing at all
and exited zero. No error line, because akbasic_runtime_error() intercepts for
the trap and deliberately prints nothing; and no handler, because the parse
branch of process_line_run() then set run_finished_mode regardless -- QUIT for a
file -- so the next line boundary the handler would have been entered at never
came. Arming an error handler made errors disappear.

The guard is to set the finished mode only when the error was actually reported.
The runtime path was always right: report_and_reraise() never touched the mode.

The same branch also never recorded the status, so the handler that now runs was
handed ER# 0. It sets lasterrorstatus from the context the way
report_and_reraise() does, and a trapped SCALE with no arguments reports 512.

Found while writing the error-code appendix -- documenting what ER# can hold
means provoking each code, and this is what happened on the way.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Andrew Kesterson
2026-08-01 07:36:00 -04:00
parent 5c5bf63356
commit 48f650c3af
3 changed files with 80 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
TODO.md
View File

@@ -1592,11 +1592,27 @@ fix is reverted:
`PASS`. A `VERIFY` against a file that did not match, which is an ordinary user answer rather
than a fault, came out as a stack trace and would have taken an embedding host with it.
`tests/housekeeping_verbs.c`.
3. **An armed `TRAP` made a parse error vanish outright.** Found the same way, writing §8
item 11's error-code appendix: a program with `TRAP` set and a line that would not parse
printed *nothing at all* and exited zero. No error line, because
`akbasic_runtime_error()` intercepts for the trap and deliberately prints nothing; and no
handler, because the parse branch of `process_line_run()` then set `run_finished_mode`
regardless — QUIT for a file run — so the next line boundary the handler would have been
entered at was never reached. **Arming an error handler made errors disappear**, which is
the exact opposite of the verb's purpose, and it was silent in both directions.
Neither was on any list. Both were found by writing down what a chapter claimed and then
The guard is one `if`: set the finished mode only when the error was actually reported.
The runtime path was always right, because `report_and_reraise()` never touched the mode.
**And the same branch never recorded the status**, so the handler that now runs was
handed `ER# 0`. It sets `obj->lasterrorstatus` from the context the way
`report_and_reraise()` does, and a trapped `SCALE` with no arguments now reports 512.
Both halves in `tests/trap_verbs.c`.
None of the three was on any list. All were found by writing down what a chapter claimed and then
running it — which is the argument for the harness rather than a footnote to it.
**A third is open, and it is the same defect as item 2 on a path that fix did not cover.**
**A fourth is open, and it is the same defect as item 2 on a path that fix did not cover.**
Writing `docs/14-architecture.md` meant describing where the boundary between a script's
error and the host's error actually sits, and the answer is: around parsing and around
`interpret()`, but **not around scanning**. `akbasic_runtime_process_line_repl()` and