The stack trace takes too much space when breaking on an exception

[karthiknadig]

This is from Survey feedback:

The stack trace takes too much space when breaking on an exception

[DonJayamanne]

Unfortunately there's really nothing we can do about this. As this is a UI issue in VSC.
The debugger returns a stack trace, and that's displayed by VSC.
We have no control over the UI of the exceptions displayed.

[qubitron]

@karthiknadig @DonJayamanne just-my-code should help here, can we verify we hide most of the stdlib in the exception stack?

[karthiknadig]

No, just-my-code is about code-stepping and breaking on exceptions. We should not remove stdlib frames from the call stack. We only remove the debugger frames since they are not relevant to user code.

[qubitron]

Just did some testing, a couple of thoughts.

First: previously we did not show the call stack in the exception message, since the call stack is also shown in the call stack window. My vote would be to remove the call stack from the exception message. If we want the stack in the exception message, then we should track this as an upstream issue and open an issue on vscode to make this error dialog have a max height and be scrollable.

It is indeed overwhelming for even the simplest of apps, see below before/after screenshot for a simple flask app.

Old debugger:

New debugger:

Secondly, we DO hide the stdlib frames from the call stack when debugstdlib is on (both in the old and new debugger), this is how JMC in Visual Studio works.

Third, in the future we should consider adding a flavor of just my code that disables debugging in site packages. Files in the site packages folder are not my code, so perhaps we should leave the option named as debugstdlib until we have true support for JMC.

[DonJayamanne]

• Old version of Debugger used to show the stack trace too (but later a bug got introduced that broke the feature)
• Also, other debuggers display stack trace in UI
• As for the exception details UI taking too much space, that's an upstream issue in VS Code.
  We have no control over the size of the exception info displayed.

Filtering of stack trace for just my code is a separate issue.

So the decision we need to make is:

• Do we need to do anything?
• If we were to limit the number of lines display in the stack trace, what would that be?
  • My suggestion is to limit this to the last 20 lines
• If we were to limit the number of characters display in the stack trace, what would that be?

/cc @qubitron @brettcannon @karthiknadig @d3r3kk

[d3r3kk]

I think my preference here:

If we were to limit the number of lines display in the stack trace...

...would be to not limit it at all, or limit it by using a 'collapse' style visualization where the last N lines are shown, but all the lines in the stack trace are available by 'un-collapsing' it.

[DonJayamanne]

using a 'collapse' style visualization where the last N lines are shown, but all the lines in the stack trace are available by 'un-collapsing' it.

This is something VSC will have to do, out of our hands.

[qubitron]

Also let's keep in mind the full stack trace is shown in the call stack window, so filtering to the last ~20 lines with "... see the debug tab for the full call stack" would be a fine solution!

[DonJayamanne]

This requires an upstream change, as well as a change in the Python extension.
microsoft/ptvsd#582

Both changes (extension and PTVSD) need to be done together

[cssyphus]

Please note that there is no way to close that gigantic red stack trace dialog either - it auto-closes only when the debugger is stopped, which is not often desirable (esp. since variable values are then lost). So that big red box is very much in the way whilst debugging.

My vote is to shrink the error report content back to minimal size (20 lines would still be far too much), but add concise, clear instructions for how to open the call stack window to view the full stack trace.

Note that there is also a StackOverflow question (with bounty) on this very issue.

[karthiknadig]

@DonJayamanne the fix for this is in master of ptvsd. There is a new setting that can be used to limit the number of frames, e.g., maxExceptionStackFrames: 5, VSC should pass this to ptvsd. By default ptvsd will return all frames, this is to preserve existing Visual Studio behavior.

[luabud]

Fixed upstream, closing in favour of #5117