Reference

Debugger

Zornux ships a native debugger. Set breakpoints, step through code, inspect variables, and evaluate watch expressions. Like the language server, it is editor-independent: it speaks the Debug Adapter Protocol, so any DAP editor works.

Getting started

bash

zornux debug app.zx     # interactive terminal debugger
zornux debug .          # debug a multi-file project
zornux dap app.zx       # DAP server over stdio (for editors)
zornux test --debug     # debug the first failing test

Terminal commands

Command	Does
`break <line>`	Set a breakpoint (snaps to the next executable line).
`run`	Start the program.
`continue`	Run to the next breakpoint.
`step`	Step into the next line.
`next`	Step over a call.
`out`	Run until the current function returns.
`stack`	Show the call stack.
`vars`	Inspect variables in the current frame.
`eval <expr>`	Evaluate a watch expression.
`quit`	Stop debugging.

A session

text

(zdb) break 6
Breakpoint at line 6.
(zdb) run
Paused at line 6 (breakpoint)
(zdb) vars
[Locals]
  price = 12 (Number)
  quantity = 3 (Number)
(zdb) eval price * quantity
36 (Number)
(zdb) continue
Program finished.

What you can inspect

Locals and parameters in the current function.
Object fields — including private fields, inside their own methods.
Service state inside a web route.
Module variables at the top level.
The full call stack, including recursion.

Breakpoints everywhere

Breakpoints work inside modules and packages, and inside service routes — a route breakpoint fires when a request runs, with no network listener required. It reports problems in the ZX1700–1799 range.

Breaking on errors

The debugger pauses on runtime errors and assertion failures so you can inspect the moment things go wrong, and you choose which errors count:

Uncaught errors — only the ones that escape every try, protect, and expect … to throw. This is the default: an error a try recovers from is part of how the program works, not a failure to stop at.
All errors — every error raised, including one a guard recovers from. Useful when you want to watch recovery happen.

An editor shows these as checkboxes; turn both off and errors never pause the run. Breakpoints land on exactly the lines you wrote, every run.

The debugger and the language server are deliberately separate: the LSP provides editing intelligence, the debugger provides execution control.