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

No traceback for errors raised in the debug console #328

Closed
yaarsh opened this issue Jul 7, 2020 · 1 comment
Closed

No traceback for errors raised in the debug console #328

yaarsh opened this issue Jul 7, 2020 · 1 comment

Comments

@yaarsh
Copy link

yaarsh commented Jul 7, 2020

Hey,
I just started using VS-code as my python IDE, for it's remote development support.
When i use the debugger to stop at some breakpoints, i often write some lines straight in the debug console (use it as interactive python shell within my program).

The problem is, when i have errors in these lines, when typed from the debug console, i don't see the full python-style traceback of the error, but only the last line (<Error_type>: ). i.e. without references to code file where the error was raised, the line raised it, and the full stack trace.

Environment data

  • VS Code version: 1.46.1

  • Extension version (available under the Extensions sidebar):
    Python 2020.6.91350
    Remote - SSH : 0.51.0

  • OS and version: win7 local, ubuntu 16.04 remote

  • Python version (& distribution if applicable, e.g. Anaconda): 3.7

  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda

  • Relevant/affected Python packages and their versions: XXX

  • Relevant/affected Python-related VS Code extensions and their versions: XXX

  • Value of the python.languageServer setting: Jedi

Expected behaviour

see full backtrace of an error, when executing line from the debug console

Actual behaviour

see only the exception type and message, without referencing to the file and line that raised the error, and the stack trace.

Steps to reproduce:

i wrote a file named tmp2.py, which contains:

class A:
    def __init__(self, val):
        print(val)

a = A()

if i put debug point on line 5: print('start'),
and then from the debug console type directly a = A(), i see this one line output:

TypeError: __init__() missing 1 required positional argument: 'val'

but if i run the full program i see the this elborated output:

Traceback (most recent call last):
  File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/innereye/.vscode-server/extensions/ms-python.python-2020.6.91350/pythonFiles/lib/python/debugpy/__main__.py", line 45, in <module>
    cli.main()
  File "/home/innereye/.vscode-server/extensions/ms-python.python-2020.6.91350/pythonFiles/lib/python/debugpy/../debugpy/server/cli.py", line 430, in main
    run()
  File "/home/innereye/.vscode-server/extensions/ms-python.python-2020.6.91350/pythonFiles/lib/python/debugpy/../debugpy/server/cli.py", line 267, in run_file
    runpy.run_path(options.target, run_name=compat.force_str("__main__"))
  File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 263, in run_path
    pkg_name=pkg_name, script_name=fname)
  File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 96, in _run_module_code
    mod_name, mod_spec, pkg_name, script_name)
  File "/home/innereye/anaconda2/envs/py3tf2/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/innereye/deeplearning/tmp2.py", line 6, in <module>
    a = A()
TypeError: __init__() missing 1 required positional argument: 'val'

which direct me to the actual file and line where the error raises.

@karthiknadig karthiknadig transferred this issue from microsoft/vscode-python Jul 7, 2020
@fabioz
Copy link
Collaborator

fabioz commented Jul 23, 2020

This was done mostly because we don't want to show the debugger stack trace along, but I think we should be able to show only the user stack trace in this case while still hiding the debugger paths.

I'll take a look at it.

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

2 participants