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

Provide more targeted/terse error messages when failing to add breakpoints #60183

Open
DanTup opened this issue Feb 20, 2025 · 0 comments
Open

Comments

@DanTup
Copy link
Collaborator

DanTup commented Feb 20, 2025

https://dart-review.googlesource.com/c/sdk/+/409280 wires up the messages for failed breakpoints to the UI for DAP-based clients (like VS Code) so that users can better understand the reason for grey/invalid breakpoints (for example whether they're in invalid locations, or the script just hasn't been compiled yet).

The current messages thar we get back (as RPCErrors) are very wordy and contain redundant information (in this context):

addBreakpointWithScriptUri: Cannot add breakpoint at line 8. Error occurred when resolving breakpoint location: No debuggable code where breakpoint was requested.

This doesn't fit nicely into a tooltip, and:

  • "addBreakpointWithScriptUri" is an internal method name that is irrelevant to the user
  • "Cannot add breakpoint at line 8" doesn't add anything that isn't already obvious in the context of a grey breakpoint on line 8
  • "Error occurred when resolving breakpoint location" also provides no useful information

"No debuggable code where breakpoint was requested" is the only text we really want to show the user in a tooltip on the grey breakpoint. We're currently using a regex to extract this, but if the overall message changes (or if there are other messages that the regex doesn't match) then the errors might not be ideal.

It would be nice if we could get a terse string for just "No debuggable code where breakpoint was requested" (and any other errors likely to be returned from addBreakpointWithScriptUri) that we could use directly instead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant