# VSCode Debugger not hitting breakpoint in include file
**URL:** https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014
**Category:** General Usage
**Tags:** vscode
**Created:** [September 3, 2020, 4:00pm UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014 "2020-09-03T16:00:35Z")
**Posts on this page:** 7
**Page:** 1
### Author:  [@Brad\_Carman](https://discourse.julialang.org/u/Brad_Carman)
#### Post date: [September 3, 2020, 4:00pm UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/1 "2020-09-03T16:00:35Z")
If I set a breakpoint in an included file, the breakpoint is not getting hit. Below shows my setup. I simply click the debug button to run test1.jl, the debugger runs and never stops at the break point. Running Julia 1.5.0 and VS Code extension is 1.0.6
Am I doing something wrong? I think this used to work
---
### Author:  [@seiji](https://discourse.julialang.org/u/seiji)
#### Post date: [May 21, 2021, 3:49am UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/2 "2021-05-21T03:49:10Z")
This was a while ago, but did you figure out a solution? I’m having similar issues.
---
### Author:  [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [May 21, 2021, 9:28am UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/3 "2021-05-21T09:28:23Z")
I don’t know if there was a time when that worked, but I think that breakpoints at the top level of `include`-d files cannot be hit. The reason is that when you `include` a file, the interpreter does not walk through its code in the same way as when you run it normally: its code is just turned into a `String`, which is then passed down to `include_string`. (You can see how it works in `Base._include`, in the source file `base/loading.jl`.)
As far as I understand, the debugger can stop only at the top level of the files you are directly running. And it also stops in the code of included files, if it is used after including it, e.g. in functions:
Say this is “test1.jl”:
```julia
include("test2.jl")
foo()
```
And “test2.jl”:
```julia
function foo()
println("Debug me!") # here is the breakpoint
end
```
Then if you run and debug “test1.jl”, it will stop at the breakpoint.
---
### Author:  [@RGerzaguet](https://discourse.julialang.org/u/RGerzaguet)
#### Post date: [May 21, 2021, 9:35am UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/4 "2021-05-21T09:35:06Z")
This is also related to [this post](https://discourse.julialang.org/t/how-to-debug-a-script-in-existing-repl-using-vscode/60822/3) and @pfitzseb has created an issue on Github related to top level debugging, currently in backlog (see [here](https://github.com/julia-vscode/julia-vscode/issues/2146))
So do think there is currently a solution (except wrap the code into a function) but thanks to the wonderful VSCode dev, we may have one soon 🙂
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [May 21, 2021, 10:57am UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/5 "2021-05-21T10:57:56Z")
Yeah, @heliosdrm is right. It’s unlikely this will be fixed anytime soon.
#2146 is about something different (I clarified the title).
---
### Author:  [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)
#### Post date: [May 21, 2021, 2:54pm UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/6 "2021-05-21T14:54:42Z")
Maybe, instead of trying to debug the code of `include`-d files, it would be worth to think why this is wanted, and if a different work flow might be a convenient way of achieving the same goal. I have encountered myself in that situation, and this is my analysis of that personal use case:
I had two kinds of files included in my code: (a) files with auxiliary functions, and (b) scripts where I calculated things in a series of steps, and kept all results as globals because later I wanted to look back into intermediate results.
The “function libraries” were no issue: I had no need to debug them at “`include` time”; maybe I wanted to add breakpoints and debug the functions when I called them later on, but there is no problem with that.
Now, the problem came with the scripts. But why was I executing them with `include` in the middle of a Julia session? Why the command of “Debug File in New Process” available in the VS Code extension was not good for me? There might be different reasons:
1. The instructions written in the script were a recipe for an analysis that might be done with different inputs. I created those inputs interactively in the REPL (e.g. reading from files), stored them in variables with fixed names, and then just `include`d the script to run the analysis – which expected those variables with those names. After that, again in the REPL I inspected final and intermediate results, plotted this and that, etc. Running the file that I wanted to debug was just a step in between an interactive session, so this could not be done in a separate new process.
2. Related to the previous reason: there might be a stage where the interactive toying with inputs and outputs was not needed anymore, I was always doing the same, so everything could be written in a script. But when dealing with multiple repetitions of the analysis (with different inputs), I still wanted to look closely into the process for each input. Run it with data A – ok, everything fine; let’s go with data B – oh, that’s not right, I’ll repeat it in debug mode in order to see what’s happening. This might be done with “Debug File in New Process”, but having to start it in a new process may be slow and annoying.
3. Different steps of the analysis were written in different scripts, and nested with `include` in the main script.
For #1 and #2, I realised that what I really wanted to do (run the whole script in a single step) was as easy and fast with the interactive tools of VS Code as by typing `include("script.jl")`. And those tools also allowed me to stop in a given line without breakpoints, e.g. starting a new code cell right before the target code block, and running the file by code cells (Alt + Shift) – well, except if I wanted to stop right in the middle of a loop or another code block.
What I really missed is some kind of shortcut that does the same as “Send Current Line or Selection to REPL” (Ctrl + Enter), but prepended by `@run` or `@enter`, to start debugging the target line without having to copy-paste it manually in the REPL.
For #3, well, I had no solution. So I have accustomed myself to avoid that pattern of nesting `include`s in scripts. Looking into it with another perspective, I think that this has also helped me to write cleaner code, e.g. replacing such things by functions when suitable.
---
### Author:  [@Baboon](https://discourse.julialang.org/u/Baboon)
#### Post date: [June 7, 2024, 1:05am UTC](https://discourse.julialang.org/t/vscode-debugger-not-hitting-breakpoint-in-include-file/46014/7 "2024-06-07T01:05:15Z")
Discussion on #1674 seems to indicate otherwise…