Repository navigation
Let debug step-into toggleable between project code and all Dart code #1291
Description
Sometimes you're debugging something and land into upstream dependent code and by default, it makes sense to get out of there as soon as possible while stepping. But sometimes you really want to know exactly what code it's running and want to step into or step next while still in that non-user code.
Activity
DanTup commentedon Nov 8, 2018
We can't change the debug UI in VS Code, so I wonder if a toggle on the status bar would work? To avoid having too many options/long labels, we'd probably want to lump libraries + sdk together (the standard options have these separated) and it should probably only persist in memory (eg. for the VS Code session or the debug session) and not modify the underlying options.
Probably the easiest way is by calling setLibraryDebuggable on everything again, though doing something like JS's
smartStepmay also work (which just steps repeatedly until you get back to the code you want).DanTup commentedon Nov 8, 2018
(btw - do you know of any other IDEs that already handle this well that might be worth copying?)
bsutton commentedon Nov 20, 2019
My preferred methods would be:
The toggle would control if the code breaks in user land (default) or library land.
If I land in library code, I can use the 'step out' button until I hit user code or else I can set a break point in the user code and let the code run until I hit my new break point.
This is essentially what eclipse does.
Eclipse also allows you to set a break point on an exception type (e.g. break on NPE), but it sounds like that's not a option (you stated you can't change the vs code interface).
If that was an option, then my primary gripe about eclipse is that you often have badly written library code that throw the likes of an NPE as part of normal processing. In these cases the above noted toggle should also cause should be applied in the same way. If the exception never hits user code then the debugger is allowed to ignore it.
DanTup commentedon Nov 20, 2019
Right now we only have one way to control breaking behaviour in the VM and that's be marked a library as "debuggable" or "not debuggable". This controls whether you'll step into them when you step, or just step over them (like they're black-boxes that can't be debugger).
I believe exceptions ignore this setting, so they will always break at the source (and whether they break depends on whether you've set uncaught exceptions or not - though there are some quirks around this with async code). However if you've set the libraries to be non-debuggable, then in VS Code we will automatically jump up the call stack to the first frame of "user code" since if you're disabled stepping in SDK/packages, you probably want to see the exceptions at the place where your code called into it (for example if your exception is an index out of range, you'd likely want to see where your code tried to index with the wrong number rather than the
throwline inside the list implementation).The way I would like to implement this is something on the status bar that just toggles those booleans. Ideally it'd be a pop-up list that lets you select between the options (or tickboxes), however I don't think VS Code lets have menus there - so it'd probably either have to be a standard picker in the command palette (like when you click a device name), or we could cycle through the options as you click on the status bar updating the text. If anyone thinks one of these is significantly better than the other (or has another idea), let me know!
DanTup commentedon Nov 21, 2019
Thinking of something like this:
Add a status bar item to quickly toggle between debug options
bsutton commentedon Nov 22, 2019
The status bar sounds like a nice idea.
I'm assuming this will take affect immediately.
e.g. I set a break point in a package library.
Click the 'Debug my code' mode and then when I run the code breaks in the package (or sdk) and I can immediately start stepping.
DanTup commentedon Nov 22, 2019
That's correct - when you toggle it it will a) update your user settings and b) send the new settings over to the debug adapter to be immediately sent to the VM :)