# Breakpoint issues and best practices in VSCode

**URL:** <https://discourse.julialang.org/t/breakpoint-issues-and-best-practices-in-vscode/122914>\
**Category:** VS Code\
**Created:** [November 21, 2024, 11:59pm UTC](https://discourse.julialang.org/t/breakpoint-issues-and-best-practices-in-vscode/122914 "2024-11-21T23:59:10Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![Nathan\_Boyer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nathan_boyer/32/14825_2.png) [@Nathan\_Boyer](https://discourse.julialang.org/u/Nathan_Boyer)\
**Post date:** [November 22, 2024, 3:15pm UTC](https://discourse.julialang.org/t/breakpoint-issues-and-best-practices-in-vscode/122914/3 "2024-11-22T15:15:48Z")

</div>

I have had trouble with this myself. (See [this Issue](https://github.com/julia-vscode/julia-vscode/issues/3335) and [this Discourse post](https://discourse.julialang.org/t/how-to-use-vscode-and-repl-to-write-and-test-a-package/78818). I don’t think either are really resolved unfortunately.)

One obvious thing I was missing initially is that you need to run the debugger on code that **calls** your functions not on the code which **defines** your functions. The breakpoints are set in the source code files, but the debugger is usually run from a separate file. You can either create a file for testing your functions yourself and click the GUI button for “Julia: Debug File in New Process” on that file, or you can use [these macros](https://www.julia-vscode.org/docs/dev/userguide/debugging/#Debugging-code-from-the-REPL) to start debugging from the REPL e.g. `@run f(x)`.

Typically now, I will try the `@enter` macro first, and if that is too slow, I will switch to using Infiltrator.jl. Infiltrator works faster and more reliably, albeit with fewer features.  
.

---

_[View the full topic](https://discourse.julialang.org/t/breakpoint-issues-and-best-practices-in-vscode/122914)._