spyder doesn't show chained exceptions (py3)

Created on 20 Jan 2016  路  8Comments  路  Source: spyder-ide/spyder

try:
    v = {}['a']
except KeyError as e:
    raise ValueError('failed') from e

In spyder the chained exception seems suppressed:

In [1]: try:
   ...:     v = {}['a']
   ...: except KeyError as e:
   ...:     raise ValueError('failed') from e
Traceback (most recent call last):

  File "<ipython-input-1-99783b362421>", line 4, in <module>
    raise ValueError('failed') from e

ValueError: failed

In the jupyter-qtconsole we see the expected chained exception:

In [1]: try:
   ...:     v = {}['a']
   ...: except KeyError as e:
   ...:     raise ValueError('failed') from e
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)
<ipython-input-1-99783b362421> in <module>()
      1 try:
----> 2     v = {}['a']
      3 except KeyError as e:

KeyError: 'a'

The above exception was the direct cause of the following exception:

ValueError                                Traceback (most recent call last)
<ipython-input-1-99783b362421> in <module>()
      2     v = {}['a']
      3 except KeyError as e:
----> 4     raise ValueError('failed') from e

ValueError: failed
IPython Console Enhancement

Most helpful comment

Closing because this was fixed upstream

All 8 comments

This happens because we're using the plain style of showing tracebacks in qtconsole. And we're doing that to be able to parse tracebacks and make them clickable to open the file to which the traceback points to.

Clickable links are all well and good, but if I had to choose I'd want to have more context to my exceptions. I might be biased though since I just spent half an hour going down the wrong track because spyder hid the root cause exception from me :(

Maybe an option to choose between clickable links and chained exceptions would be a good interim step until we can have our cake and eat it too!

Come on, this needs to be fixed.

Clickable links are nice, but right now it means that using a from-clause after en exception is meaningless in Spyder. That means it's not conforming by the language specification: https://www.python.org/dev/peps/pep-3134/ , which I think is a pretty big deal.

Also, it means a root cause is a lot harder to find. I just had a use case like this:

try:
    # Some hard code where multiple things could go wrong
    raise Exception("Something unexpected")
except Exception as ex:
    # Inspect some objects, maybe ask the user for some input, to see if the error can be safely ignored
    if not can_be_ignored:
        raise Exception("Some additional info") from ex

That means with spyder, I can't really get the information I need. I only have 2 options:

  • Gathering all information manually in the except-clause, printing some information before raising again. On StackOverflow, a lot of people are warning against use sys.exc_info(), as it can behave unpredictably. Also, it makes a mess of my console and does not give the user a clear picture of what happened.
  • Only using a bare raise, That means I have to just print or drop any results from gathering additional information. And if I change any objects in the except-clause, the user may be confused as to what code was actually run and what wasn't (he can't see from where the reraise occured)

I think this is a bug with ipython %xmode plain and should be fixed upstream:
ipython:

In [2]: %xmode plain                                                                                 
Exception reporting mode: Plain

In [3]: try: 
   ...:     v = {}['a'] 
   ...: except KeyError as e: 
   ...:     raise ValueError('failed') from e 
   ...:                                                                                              
Traceback (most recent call last):
  File "<ipython-input-3-944ebf5453bb>", line 4, in <module>
    raise ValueError('failed') from e
ValueError: failed

python:

>>> try:
...     v = {}['a']
... except KeyError as e:
...     raise ValueError('failed') from e
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
KeyError: 'a'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
ValueError: failed

@impact27, thanks for doing that. Could you help the IPython guys with that bug?

Fixed in ipython 7.10.2

Closing because this was fixed upstream

Was this page helpful?
0 / 5 - 0 ratings