classification
Title: Command-line option to suppress "from None" for debugging
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.7
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Mariatta, haypo, martin.panter, ncoghlan, rhettinger, serhiy.storchaka, wolma
Priority: normal Keywords:

Created on 2017-04-18 22:11 by rhettinger, last changed 2017-05-11 00:35 by haypo.

Messages (4)
msg291844 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2017-04-18 22:11
Filing this feature request on behalf of an engineering team that I work with.

This team creates Python tools for use by other departments.  Accordingly, their best practice is to use "raise CleanException from None" to give the cleanest error messages to their users while hiding the noise of implementation details and internal logic.  The exposed exceptions are a documented, guaranteed part of the API that users can reliably catch and handle.  This has worked well for them; however, when they are debugging the library itself it would be nice to have a way to suppress all the "from None" code and see fuller stack traces that indicate root causes.

One way to do this would be to have a command-line switch such as "python -C testcode.py".   Where the "-C" option means "Always show the cause of exceptions even when 'from None' is present.
msg291857 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2017-04-19 04:06
The initial exception still is linked as __context__. You can write own implementation of traceback.print_exception() that ignores __suppress_context__. Alternatively you can just set __suppress_context__ to False.
msg293185 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2017-05-07 09:29
This proposal would be useful. My use case is for when an API suppresses an external exception context:

>>> import os
>>> try:
...     os.environ["NEW_VARIABLE"] = bug  # Hidden exception
... finally:
...     del os.environ["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/usr/lib/python3.5/os.py", line 699, in __delitem__
    raise KeyError(key) from None
KeyError: 'NEW_VARIABLE'

This feels like a step backwards to Python 2, and enabling the full backtrace would make this easier to analyze:

>>> try:
...     os.environ["NEW_VARIABLE"] = bug  # TypeError
... finally:
...     del dict()["NEW_VARIABLE"]  # KeyError
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "/usr/lib/python3.5/os.py", line 688, in __setitem__
    value = self.encodevalue(value)
  File "/usr/lib/python3.5/os.py", line 756, in encode
    raise TypeError("str expected, not %s" % type(value).__name__)
TypeError: str expected, not object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
KeyError: 'NEW_VARIABLE'
msg293466 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2017-05-11 00:35
See also my old PEP 490 -- Chain exceptions at C level, more or less abandonned :-p
History
Date User Action Args
2017-05-11 00:35:31hayposetnosy: + haypo, ncoghlan
messages: + msg293466
2017-05-07 09:29:04martin.pantersetnosy: + martin.panter
messages: + msg293185
2017-04-20 10:20:54wolmasetnosy: + wolma
2017-04-19 04:39:15Mariattasetnosy: + Mariatta
2017-04-19 04:06:52serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg291857
2017-04-18 22:11:52rhettingercreate