Exception chaining accepts exception classes

[cool-RR]

BPO	43002
Nosy	@mdickinson, @stevendaprano, @cool-RR, @miss-islington
PRs	bpo-43002: Fix description of behaviour of an exception class in 'from' clause #24303 [3.9] bpo-43002: Fix description of behaviour of an exception class in 'from' clause (GH-24303) #25341 [3.8] bpo-43002: Fix description of behaviour of an exception class in 'from' clause (GH-24303) #25342

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2021-01-22.22:29:37.398>
created_at = <Date 2021-01-22.13:52:41.081>
labels = ['interpreter-core', 'type-bug', '3.8', '3.9', '3.10', 'invalid']
title = 'Exception chaining accepts exception classes'
updated_at = <Date 2021-04-11.08:49:04.101>
user = 'https://github.com/cool-RR'

bugs.python.org fields:

activity = <Date 2021-04-11.08:49:04.101>
actor = 'miss-islington'
assignee = 'none'
closed = True
closed_date = <Date 2021-01-22.22:29:37.398>
closer = 'steven.daprano'
components = ['Interpreter Core']
creation = <Date 2021-01-22.13:52:41.081>
creator = 'cool-RR'
dependencies = []
files = []
hgrepos = []
issue_num = 43002
keywords = []
message_count = 5.0
messages = ['385499', '385514', '385525', '385530', '385531']
nosy_count = 4.0
nosy_names = ['mark.dickinson', 'steven.daprano', 'cool-RR', 'miss-islington']
pr_nums = ['24303', '25341', '25342']
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue43002'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[cool-RR]

I saw this line of code today: hyperledger-archives/sawtooth-sdk-python@c27b962#diff-eb008203eae2160c5e14c42e5fd2eee164709a93bf5136fa79cc256d4e46eaffR92

I was about to tell this guy that his code is bad since the part after the from should be a specific exception, not just an exception class. I thought I should double-check myself first. Lo and behold:

$ cat x.py
def f():
    raise TypeError

try:
    f()
except TypeError:
    raise ValueError from TypeError

$ python x.py
TypeError

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

Traceback (most recent call last):
  File "x.py", line 7, in <module>
    raise ValueError from TypeError
ValueError

The line doesn't fail, but it silently trims away the stacktrace of the previous exception. (Normally the stacktrace would include what's inside the f function.)

I'm not sure whether this is intended behavior or not. The documentation does say "the second expression must be another exception class or instance" but (a) it's not clear what the use case is when it's a class and (b) I doubt that the person who wrote the code above, and any other person who writes such code, would be aware that their traceback got snipped until it's too late and they're stuck with a bug report with incomplete information.

[stevendaprano]

It is intended behaviour. raise ... from is a general mechanism that you can call anywhere, it is not just limited to raising from the previous exception. It is designed for explicitly setting the chained exception to some arbitrary exception. See the PEP:

https://www.python.org/dev/peps/pep-3134/#explicit-exception-chaining

>>> raise ValueError('bad value') from IndexError('bad index')
IndexError: bad index

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

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: bad value

If you wish to chain from the current exception, you have to chain from the current exception, and not create a new one.

This is not an interpreter bug, it's working fine. Your first instinct was correct: your colleague had written "bad code" and his intention was probably to raise from the exception he had just caught.

Or just don't do anything. A raise exception inside an except block will be automatically chained with the current exception unless you explicitly disable it with raise exception from None.