Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let debug step-into toggleable between project code and all Dart code #1291

Closed
xster opened this issue Nov 8, 2018 · 7 comments
Closed

Let debug step-into toggleable between project code and all Dart code #1291

xster opened this issue Nov 8, 2018 · 7 comments
Labels
in debugger Relates to the debug adapter or process of launching a debug session is enhancement
Milestone

Comments

@xster
Copy link

xster commented Nov 8, 2018

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.

@DanTup
Copy link
Member

DanTup commented 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 smartStep may also work (which just steps repeatedly until you get back to the code you want).

@DanTup DanTup added this to the On Deck milestone Nov 8, 2018
@DanTup DanTup added is enhancement in debugger Relates to the debug adapter or process of launching a debug session labels Nov 8, 2018
@DanTup
Copy link
Member

DanTup commented Nov 8, 2018

(btw - do you know of any other IDEs that already handle this well that might be worth copying?)

@bsutton
Copy link

bsutton commented Nov 20, 2019

My preferred methods would be:

  1. a toggle which controls where your code breaks when the debugger breaks on an exception (e.g. break on uncaught exceptions).
    The toggle would control if the code breaks in user land (default) or library land.
  2. If I set a break point in library land or the code breaks in library land (as a result of 1) then stepping works as normal.
    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
Copy link
Member

DanTup commented 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 throw line 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
Copy link
Member

DanTup commented Nov 21, 2019

Thinking of something like this:

Nov-21-2019 1-44-33 pm

@bsutton
Copy link

bsutton commented 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
Copy link
Member

DanTup commented 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 :)

@DanTup DanTup closed this as completed in c59bbcf Nov 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in debugger Relates to the debug adapter or process of launching a debug session is enhancement
Projects
None yet
Development

No branches or pull requests

3 participants