Debug: Failed to eval expression with watches

[andig]

What version of Go, VS Code & VS Code Go extension are you using?

• Run go version to get version of Go

  go version go1.13.6 darwin/amd64

• Run code -v or code-insiders -v to get version of VS Code or VS Code Insiders

  1.41.1
  26076a4de974ead31f97692a0d32f90d735645c0
  x64

• Check your installed extensions to get the version of the VS Code Go extension

  0.12.0

• Run go env GOOS GOARCH to get the operating system and processor arhcitecture details

  darwin
  amd64

Describe the bug

During debugging, with some watches added, the debug console gets flowed with lengthy output of

Failed to eval expression:  {
"Expr": "enabled",
"Scope": {
"goroutineID": 42,
"frame": 0
},
"Cfg": {
....

as soon as a breakpoint is hit. The problem seems to be that obviously not all watches exist in the same scope (or maybe same goroutine) and vscode-go/delve errors on the ones that are not accessible.

Instead, these errors should be suppressed (or go to the terminal window) and not clutter the debug console that shows the application output.

Steps to reproduce the behavior:

1. Set breakpoint, open debug console
2. add various watches, especially outside breakpoint's scope
3. run application
4. hit breakpoint and notice error in debug console

[ramya-rao-a]

Thanks for reporting @andig

Unfortunately, the extension is not aware of which watches exist in the current scope and which don't. Therefore, I don't see a good way to suppress these errors that come from delve.

@quoctruong any ideas?

[andig]

Thanks for taking up this request!

Unfortunately, the extension is not aware of which watches exist in the current scope and which don't.

In that case I would suggest to suppress all errors or that type or potentially use the errors to provide dynamic filtering of the watches (greyed out or hidden = did error and is hence not available). It seems the errors are recognizable as such. Might also make sense to work with delve to not even send these as they're really meaningless in this context.

At any rate I'd not expect them mixed with the application's output- wouldn't mind if they appeared in the vscode terminal window instead;)

[ramya-rao-a]

Do you see this even without setting the trace field in the debug configuration to log or verbose?
This can be useful in the verbose mode.
In any other mode, we can look into hiding these

[andig]

Do you see this even without setting the trace field in the debug configuration to log or verbose?

Where could I check? The only go setting I've really tweaked is enabling of the language server.

[quoctruong]

You can set the trace setting in the debug configuration that you use in launch.json. It can be set to log, verbose or error.

[andig]

I feel stupid, but there is no "debug configuration" or trace key, so I'm seeing this at the default values:

    {
        "name": "EVCC PROD",
        "type": "go",
        "request": "launch",
        "mode": "auto",
		"program": "${workspaceFolder}/main.go",
        "env": {},
        "args": ["--uri","127.1:7070","-c","evcc.wallbe.yaml"]
    }

[defrancr]

@andig, you can add the key to the configuration. This is mine as an example:

{
  "name": "WebServer",
  "type": "go",
  "request": "launch",
  "mode": "auto",
  "program": "${fileDirname}",
  "trace": "error",
  "serverReadyAction": {
    "action": "openExternally"
  },
  "env": {
    "SCRUT_WEB_DEBUG":"1",
  }
}

@ramya-rao-a, even with "trace": "error" it still shows the Failed to eval expression when out of scope.

[shimonacarvalho]

Agree on needing some sort of solution for this - hard to see the real errors when every step displays a whole bunch of watch errors.

[ramya-rao-a]

I agree on these errors being noise.
We can modify the above to be a warning instead such that it shows up only when trace is set to log or verbose.

I've made this change that you can try out in the latest beta version of this extension.

[andig]

I've made this change that you can try out in the latest beta version of this extension.

LGTM- I've only tested the "regular" case without setting log to any non-default value.

[ramya-rao-a]

Thanks @andig

The fix associated with this issue is now available in the latest version of the extension