Exception-Traceback-Guided Debugging
- Exception-traceback-guided debugging is a technique that uses runtime error artifacts like exception tracebacks to pinpoint fault-relevant code and trigger repair cycles.
- The approach integrates methods such as local code structure extraction, custom-code filtering, and multi-agent workflows to address the limitations of raw trace data.
- Empirical results demonstrate that iterative repair strategies and hybrid designs significantly improve code execution rates, fault localization precision, and user satisfaction.
Searching arXiv for the cited works to ground the article in current paper metadata. arXiv search query: (Yuan et al., 7 Jan 2025) exception traceback debugging TraceCoder TraceFixer CrashTracker stack traces fault localization Exception-traceback-guided debugging denotes a family of debugging techniques in which a runtime failure artifact—most commonly an exception traceback or crash stack trace, and in some systems a richer execution trace anchored at an exception event—is used to localize fault-relevant code, recover execution context, and drive repair, explanation, or subsequent experimentation. In recent work, the traceback is treated not merely as terminal output but as a control signal for automated research code repair, multi-agent diagnosis, framework-aware crash localization, and repository-aware exception handling (Yuan et al., 7 Jan 2025, Huang et al., 6 Feb 2026, Yan et al., 2024).
1. Conceptual scope and debugging substrate
At its narrowest, the technique uses the raw exception traceback itself as the primary debugging substrate. BLVRUN, for example, captures the traceback output from Python execution and feeds it to a fine-tuned local model to produce a concise summary for blind and low-vision programmers; its input is the raw traceback text rather than a separately specified symbolic representation (Saben et al., 2024). The voice-assisted Python plugin built around sys.excepthook similarly treats the standard exception triad—exception type, exception value, and traceback object—as the central diagnostic input, then serializes the traceback with traceback.format_exception(...) and derives audible and visual summaries from exception type, message, file names, line numbers, traceback depth, and call-stack hierarchy (Amiri et al., 20 Jul 2025).
A broader interpretation extends traceback guidance into context-sensitive debugging interfaces. In moldable exceptions, the exception object itself can expose debugger-specific views, actions, and activation logic through <gtExceptionView>, <gtExceptionAction>, and <gtDebuggerSpecification> methods, so the debugger adapts to exception-time context rather than presenting only a generic stack/source/locals interface (Chiş et al., 2024). A further extension appears in grounded-theory observations of professional debugging practice: developers often begin from a concrete runtime failure signal, then alternate between navigation and execution while using backward tracing and forward tracing to update a mental model of uncertainty and speculations (Li et al., 11 Feb 2026). This suggests that exception-traceback-guided debugging is best understood not as a single parser or ranker, but as a family of workflows in which the failure artifact becomes the anchor for iterative diagnosis.
Not all closely related systems are traceback-centric in the strict sense. TraceCoder broadens the substrate from exception traces to runtime traces containing control-flow evidence, variable-state evidence, intermediate program states, and failure diagnostics, while TraceDiff and TraceFixer work from execution divergence rather than crash stacks (Huang et al., 6 Feb 2026, Suzuki et al., 2017, Bouzenia et al., 2023). Their relevance lies in showing how traceback guidance can be embedded in richer dynamic evidence rather than replaced by static code context alone.
2. From traceback to fault-relevant context
A central technical issue is that the observed traceback is only a partial view of the failure-producing execution. CrashTracker formalizes this by distinguishing the full crash-triggering execution trace,
from the observed crash trace,
The stack trace therefore contains only methods still on the runtime stack when the exception is thrown; the real buggy method may already have returned and may not appear in the traceback at all (Yan et al., 2024). This observation recurs across the literature and explains why traceback-guided techniques usually add a localization stage rather than treating the top frame as the root cause.
Dolphin gives a procedural formulation of this localization step inside an LLM-driven research loop. When generated research code fails, Dolphin captures the exception traceback, extracts the function name, line, and code, restricts attention to custom code while excluding library function calls, prompts the LLM to generate the relevant local code structure, then feeds the exception traceback together with that local code structure back to the model for repair (Yuan et al., 7 Jan 2025). “Local code structure” is not a global repository representation; it is a traceback-conditioned, custom-code-focused structural context intended to expose nested calling relationships and the error-related lines that surround the failure path. The stated motivation is that LLMs struggle with “complicated nested relationships (e.g., between class and function),” so a one-line traceback or a whole repository view is often poorly targeted.
A recurrent misconception is that raw traceback text alone is sufficient. Dolphin’s own ablation is explicit that raw traceback alone is insufficient, and that local code structure without traceback guidance is also insufficient, because the model may produce or copy irrelevant reference code (Yuan et al., 7 Jan 2025). TraceCoder reaches a comparable conclusion from a different direction: its Instrumentation Agent adds non-invasive print statements so that the Analysis Agent receives not only runtime errors or exception traces, but also control-flow signals and intermediate state evidence capable of supporting causal reasoning (Huang et al., 6 Feb 2026). The same logic appears in stack-trace-based fault localization: SBEST treats the stack trace as a proxy failing execution, but then augments it with coverage from tests whose executions most overlap with the top internal stack-trace methods (Pacheco et al., 2024). CatchAll performs a static analogue of traceback expansion by constructing a depth-bounded contextual call trace over repository code, intended to simulate exception propagation across files and methods (Tao et al., 3 Jan 2026).
3. Repair loops, control strategies, and formalization
Most exception-traceback-guided systems are procedural rather than optimization-based. Dolphin provides no loss function or formal debugging objective; its debugging component is an iterative loop: generate or modify code, execute it, capture traceback on failure, extract function name/line/code, filter out library frames, generate local code structure, prompt the LLM for repair, re-execute, and stop on success or after a maximum debugging budget (Yuan et al., 7 Jan 2025). The implementation details reported for experimental verification include a maximum of 5 debugging attempts, an initial self-reflection step “to eliminate some syntax errors before executing the program,” the use of aider as the framework to call LLM agents, and deepseek-v2.5 deployed via ollama.
TraceCoder makes the control structure more explicit by separating observation, diagnosis, and intervention into three agents. Its Instrumentation Agent maps the current faulty code, recent failure feedback, and optional instrumentation guidance into instrumented code; the Analysis Agent maps the problem description, instrumented code, runtime traces, and lesson history to a repair plan and next-step instrumentation suggestion; and the Repair Agent maps the problem description, current faulty code, test failure feedback, and structured repair plan to a repaired candidate (Huang et al., 6 Feb 2026). Two cross-cutting mechanisms further regulate the loop. The Historical Lesson Learning Mechanism stores failed repair plans, resulting failure feedback, failed repaired code, and the number of tests passed, so later iterations can reason over recurring pitfalls. The Rollback Mechanism enforces “strict improvement” in the precise sense that the number of passed tests must increase beyond ; otherwise the system either continues under stagnation or rolls back to the best-known candidate.
Repository-aware exception handling systems adapt the same logic to preventive repair rather than post-crash patching. CatchAll predicts likely exception types for a snippet using an empirically mined API–exception mapping and a repository-level contextual call trace, retrieves similar historical try-catch blocks using exception-type similarity, API sequence similarity, and try-block similarity, abstracts them into a parameterized handling pattern, and finally generates a repository-consistent catch block (Tao et al., 3 Jan 2026). Here the traceback analogue is static rather than dynamic: repository context approximates exception propagation when no actual runtime stack is available.
TraceFixer is best read as an adjacent, rather than central, member of this family. It uses a partial execution trace and a user-supplied desired state at a divergence point to predict a single-line repair, but it explicitly excludes programs terminated with a runtime exception and states that such cases are out of scope (Bouzenia et al., 2023). Its importance is conceptual: it shows that repair quality can improve when source edits are conditioned on dynamic evidence rather than source context alone.
4. Explanation, interaction, and developer-facing interfaces
Exception-traceback-guided debugging is not limited to automated patch generation. A substantial line of work treats the traceback as a human-facing diagnostic object whose primary function is explanation, accessibility, or interactive exploration. BLVRUN embodies the simplest form of this design: a command-line wrapper monitors Python execution, captures verbose traceback text, sends it to a locally hosted fine-tuned CodeLlama 7B model on an Ollama server, and returns a concise natural-language summary without requiring an IDE or a workflow change (Saben et al., 2024). The system is explicitly scoped to explicit runtime errors rather than silent logical faults.
The voice-assisted Python debugger generalizes summarization into multimodal delivery. After interception by a global exception hook, it formats and classifies the traceback, then launches speech and Tkinter-based visual rendering in parallel. The GUI preserves interactive stack frames and a 3-line code snippet around the failing line, while the voice engine prioritizes exception type before location and message details (Amiri et al., 20 Jul 2025). The result is neither a patch generator nor a conventional debugger replacement; it is a traceback-to-diagnostic-event transformer intended to reduce rereading and improve accessibility.
Moldable exceptions move further from summarization toward context-specific debugging views. Rather than only exposing stack frames, an exception may contribute a textual diff, a game-state view, a GUI interaction tree, or a “Fix & retry” action, depending on exception class and available context (Chiş et al., 2024). The debugger remains available in its generic form, but exception-specific views and actions let the failure object itself guide the interface. This design is especially relevant where the current stack is a poor approximation to the developer’s mental execution narrative, as in scheduled GUI interactions.
Educational and exploratory systems broaden the same principle beyond crashes. TraceDiff compares the dynamic executions of incorrect and corrected code and highlights the first divergence in variable, call, or return-value sequences, while Tracers advocates a complete execution trace showing every line “as executed” rather than “as written” (Suzuki et al., 2017, Chiplunkar et al., 10 Apr 2026). Grounded-theory evidence from professional practice helps explain why such interfaces matter: developers often begin with backward tracing from the issue, but then switch to forward tracing and alternate between navigation and execution as they refine a partial mental model (Li et al., 11 Feb 2026). A plausible implication is that exception tracebacks are most effective when they support this broader mental-model loop rather than acting as a final answer.
5. Empirical evidence across representative systems
Reported results span execution success, repair accuracy, crash localization precision, and human-centered usability outcomes.
| System | Setting | Key reported result |
|---|---|---|
| Dolphin (Yuan et al., 7 Jan 2025) | Experimental verification ablation | execution rate improved from |
| TraceCoder (Huang et al., 6 Feb 2026) | Multi-agent automated debugging | up to a relative improvement in Pass@1; iterative repair contributes a relative gain in accuracy |
| CrashTracker (Yan et al., 2024) | Android framework-specific crashing fault localization | overall MRR ; LLM explanation yields a 67.04% improvement in users' satisfaction score |
| SBEST (Pacheco et al., 2024) | Fault localization without failing tests | MAP improved by 32.22% and MRR by 17.43% over stack trace ranking |
| Hear Your Code Fail (Amiri et al., 20 Jul 2025) | Multimodal Python exception feedback | 37% reduced cognitive load and 78% faster error identification |
These results support several distinct claims. First, traceback-guided localization can improve whether generated code runs at all, which is the central concern in Dolphin’s closed-loop research setting. Second, iterative repair driven by runtime evidence can outperform both one-shot generation and breadth-only sampling, as shown by TraceCoder’s Pass@1 gains and its equal-budget comparisons against multiple-sample baselines (Huang et al., 6 Feb 2026). Third, stack traces remain highly informative even when failing tests are unavailable: SBEST reports that only 3.33% of its studied crash-report bugs have fault-triggering tests, yet 98.3% of bug-fix intentions align directly with exceptions in stack traces, and 78.3% of buggy methods are reachable within an average of 0.34 method calls (Pacheco et al., 2024). Fourth, the evidence base is not limited to accuracy metrics; accessibility-oriented systems report improvements in cognitive load, rereads, error classification accuracy, and debugging time for visually impaired or multitasking users (Amiri et al., 20 Jul 2025).
The empirical record is therefore heterogeneous rather than uniform. Some papers optimize executable repair, some emphasize ranked localization, and some measure explanation quality or user satisfaction. The common thread is that exception-derived runtime evidence is treated as a high-value anchor rather than as disposable console output.
6. Limitations, misconceptions, and open directions
The strongest recurring limitation is scope. Dolphin explicitly relies on traceback-driven repair of crashing runtime errors and does not claim detailed handling of semantic bugs that do not trigger exceptions, nor does it use assertions, tests, or performance-based debugging inside its traceback loop (Yuan et al., 7 Jan 2025). TraceCoder substantially reduces runtime errors, but its remaining dominant failure mode on BigCodeBench is Wrong Answer rather than Runtime Error, indicating that richer traces do not automatically solve silent logic defects (Huang et al., 6 Feb 2026). BLVRUN likewise supports explicit on-screen runtime errors rather than unintended behavior without an exception, and its evaluation compares summaries against 13B-generated “gold standard” summaries rather than completed human studies (Saben et al., 2024).
A second limitation concerns fidelity of context reconstruction. CatchAll’s contextual call trace is a static, depth-bounded approximation of exception propagation, not a true runtime stack trace; it may therefore include infeasible paths or miss dynamic dispatch realities (Tao et al., 3 Jan 2026). CrashTracker reduces dependence on raw call-graph expansion by introducing Exception-Thrown Summaries, but it is still weaker when the signaler or relevant framework behavior is in native code, when data relationships are implicit, or when callback interleavings violate its assumptions about stack layering (Yan et al., 2024). TraceDiff requires a corrected reference program or synthesized repair and only visualizes a single point where incorrect code diverges from correct code, which can underrepresent multi-bug or longer-horizon failures (Suzuki et al., 2017).
A third limitation is under-specification. Dolphin does not provide an exact parsing implementation for traceback extraction, an exact representation format for local code structure, or prompt wording for local-code-structure generation and debugging (Yuan et al., 7 Jan 2025). Several other systems are similarly heuristic: BLVRUN does not present a formal traceback grammar, and the voice-assisted debugger uses rule-based exception families and template selection rather than a learned semantic model (Saben et al., 2024, Amiri et al., 20 Jul 2025). This does not negate their practical value, but it constrains reproducibility and leaves substantial engineering space open.
The literature also converges on a clear corrective to an overly simple view of traceback-guided debugging. The traceback is rarely enough by itself. Effective systems usually add one or more of the following: custom-code filtering, local code structure, runtime instrumentation, historical lesson records, rollback control, exception semantics mined from framework code, repository-aware call traces, or context-specific explanation interfaces. This suggests that future work is likely to move toward hybrid designs in which exception tracebacks remain the anchor, but are embedded in fuller models of execution history, repository context, and developer interaction.
