set_breakpoint
Pauses program execution at a chosen source line, function, or statement during debugging, with optional conditions and logpoints to inspect behavior without stopping.
Instructions
Set a breakpoint. Setting breakpoints on non-executable lines (structural, declarative) may lead to unexpected behavior
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| file | No | Path to the source file or Java FQCN. For Java, passing a fully-qualified class name (e.g. "com.example.MyClass" or "com.example.Outer$Inner") is preferred — it works reliably with all classloaders including custom classloaders. Alternatively, use absolute file paths. | |
| line | No | Line number where to set breakpoint. Executable statements (assignments, function calls, conditionals, returns) work best. Structural lines (function/class definitions), declarative lines (imports), or non-executable lines (comments, blank lines) may cause unexpected stepping behavior | |
| function | No | Address by symbol name instead of file location: break on entry to this function/method (DAP function breakpoint). No file or line needed — names survive edits better than both. Composes with condition only. Supported by Python, Go, Rust, C/C++, .NET, Java, JavaScript and COBOL (paragraph, section or PROGRAM-ID names, e.g. "1000-INIT" or "1000-INIT OF PAYROLL") adapters; not by Ruby (rdbg ignores the request) or Dart (the SDK adapters have no function breakpoints). JavaScript names are dotted runtime paths (e.g. "handler" or "obj.method") bound to the current function value: top-level function declarations of the main module bind at launch; functions in modules loaded later bind at the next pause | |
| nearLine | No | With statement only: when the statement text appears on multiple lines, bind to the match closest to this line | |
| condition | No | Optional expression: only break (or log) when it evaluates truthy | |
| sessionId | Yes | ||
| statement | No | Address by content instead of line number: the text of the target line, like an Edit-tool match — a distinctive substring is enough (leading/trailing whitespace and trailing //- or #-comments are ignored; an exact whole-line match always wins over substring matches). Preferred over line — it can only land on a line containing your text (an inexact or multi-candidate match adds a warning to the response) and survives file edits across restart_debugging. If the text appears on multiple lines, the error lists every match; add nearLine to pick one. Provide statement OR line, not both | |
| logMessage | No | Create a logpoint: instead of pausing, log this message when the line is hit. Expressions in {curly braces} are interpolated (e.g. "order={orderId} total={total}"). Messages arrive in get_output while the program runs at full speed. Supported by the Python, JavaScript, Go, Rust, C/C++, COBOL ({WS-NAME} data references), Dart and mock adapters; not by Java, .NET, or Ruby | |
| suspendPolicy | No | Suspend policy when breakpoint is hit: "all" suspends all threads (default), "thread" only suspends the event thread. Only supported by the Java/JDI adapter. | |
| expectedContent | No | Optional assertion: text you expect on the target line — a distinctive substring is enough (leading/trailing whitespace and trailing //- or #-comments are ignored). If it does not match, the breakpoint is NOT set and the error shows the actual content of that line and its neighbors — use this to catch stale or off-by-one line numbers before they cause confusing behavior |