This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Display full tracebacks when an error occurs asynchronously
Type: enhancement Stage: resolved
Components: Interpreter Core, Library (Lib) Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: alonho, amaury.forgeotdarc, asvetlov, ezio.melotti, kachayev, martin.panter, oddthinking, pitrou, python-dev
Priority: normal Keywords: needs review, patch

Created on 2009-11-13 19:23 by pitrou, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
7317.patch alonho, 2011-10-15 11:05 review
7317.patch alonho, 2011-10-15 15:09 review
issue7317.diff kachayev, 2012-11-03 13:33 review
Messages (13)
msg95197 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2009-11-13 19:23
When an exception is raised in a __del__ method or a finalizer (i.e. a
weakref callback), only the exception name is printed out.
Unfortunately, arbitrarily complex code can be involved which makes
debugging quite tedious. It would be nice to display the full traceback
so that these errors are easier to diagnose (see issue7060 as an example).
msg95867 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2009-12-01 16:59
Seconded. 
But such messages are also printed when the interpreter exits, when
poorly written __del__ methods access already disposed modules. Raising
a full traceback could cause users to think that the error is more
severe than it is.

Is there an already existing flag that could control this behaviour?
Otherwise, well, just ignore my remark.
msg120374 - (view) Author: Julian (oddthinking) Date: 2010-11-04 03:41
Amaury asks: "Is there an already existing flag that could control this behaviour?"

I wonder if the warnings module could be used.
msg145586 - (view) Author: alon horev (alonho) * Date: 2011-10-15 11:05
Submitting a patch proposing this format:

-----BEGIN UNRAISABLE EXCEPTION-----
Class: AttributeError
Instance: "'NoneType' object has no attribute 'someattr'"
Function: <bound method A.__del__ of <__main__.A object at 0x1007671d0>>
Traceback (most recent call last):
  File "/tmp/bla.py", line 4, in __del__
    None.someattr
-----END UNRAISABLE EXCEPTION-----

I've wrapped the exception information with header/footer differentiating it from a user's error handling code that also prints tracebacks (is it too much?).

I've considered using the warnings module, But I dislike the suppression of already warned messages. (2 instances will raise exception in __del__ but only one message will be printed) 

This is my first patch submission so feel free giving me a hard time.
msg145589 - (view) Author: Julian (oddthinking) Date: 2011-10-15 12:28
The formatting isn't very conventional for Python.

Why not use the normal format? i.e.
 
Traceback (most recent call last):
  File "/tmp/bla.py", line 4, in __del__
    None.someattr
AttributeError: 'NoneType' object has no attribute 'someattr'

Why is this more likely to get confused with user input than other unhandled exceptions?

If you ARE going to deviate, it may be helpful to have it explain why this exception wasn't caught through the normal channels. Maybe the last line could be: "Failed to raise this exception in __del__/finalizer method." or similar.
msg145593 - (view) Author: alon horev (alonho) * Date: 2011-10-15 15:09
Here's the next attempt (took your advice about the convention):

Exception ignored in: <bound method A.__del__ of <__main__.A object at 0x1007671d0>>
Traceback (most recent call last):
  File "/tmp/bla.py", line 4, in __del__
    None.someattr
AttributeError: 'NoneType' object has no attribute 'someattr'

reminder of the current format for comparison:

Exception AttributeError: "'NoneType' object has no attribute 'someattr'" in <bound method A.__del__ of <__main__.A object at 0x1007671d0>> ignored

I thought about a more elaborate explanation than "Exception ignored" but grepping this function through the code shows it can be called from various places making it too generic.

The reason I wanted to add a header/footer is for stating the message and the traceback go together (I print tracebacks to screen all the time), but it might be TMI..
msg145610 - (view) Author: Julian (oddthinking) Date: 2011-10-16 00:56
I wish there was a less instrusive of saying "+1. I'm happy. Thanks." than posting a whole comment, but until then:

+1. I'm happy. Thanks.

(I haven't inspected the code - just based on the description.)
msg160465 - (view) Author: alon horev (alonho) * Date: 2012-05-12 09:37
how does one get his patch reviewed? (it's been 6 months)
msg167272 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-08-02 23:06
Oops, sorry for the silence, I had forgotten about this issue. I'll take a look at the patch soon.
msg174268 - (view) Author: alon horev (alonho) * Date: 2012-10-31 08:29
Hi Antoine, can you please have a look at the patch? It's been over a year since it's submitted. (-: thanks!
msg174616 - (view) Author: Alexey Kachayev (kachayev) * Date: 2012-11-03 13:33
Updated test case for traceback printing, fixed test_cmd_line crashing with new ignored exception message formatting (test was based on regular expression). Patch is attached.
msg174622 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2012-11-03 13:56
New changeset a281604a5c9a by Andrew Svetlov in branch 'default':
Issue #7317: Display full tracebacks when an error occurs asynchronously.
http://hg.python.org/cpython/rev/a281604a5c9a
msg174627 - (view) Author: Andrew Svetlov (asvetlov) * (Python committer) Date: 2012-11-03 14:48
Committed. Thanks, guys!
History
Date User Action Args
2022-04-11 14:56:54adminsetgithub: 51566
2013-03-18 20:39:04r.david.murraylinkissue1691387 superseder
2012-11-03 14:48:02asvetlovsetstatus: open -> closed
resolution: fixed
messages: + msg174627

stage: patch review -> resolved
2012-11-03 13:56:22python-devsetnosy: + python-dev
messages: + msg174622
2012-11-03 13:34:00kachayevsetfiles: + issue7317.diff
nosy: + kachayev
messages: + msg174616

2012-11-03 00:08:40martin.pantersetnosy: + martin.panter
2012-11-01 11:58:47asvetlovsetnosy: + asvetlov
2012-10-31 08:29:48alonhosetmessages: + msg174268
2012-08-02 23:07:02pitrousetmessages: - msg167273
2012-08-02 23:06:45pitrousetmessages: + msg167273
2012-08-02 23:06:09pitrousetmessages: + msg167272
2012-05-12 09:37:35alonhosetmessages: + msg160465
2011-10-17 11:46:48eric.araujosetpriority: high -> normal
keywords: + needs review
stage: needs patch -> patch review
versions: + Python 3.3, - Python 2.7, Python 3.2
2011-10-16 00:56:38oddthinkingsetmessages: + msg145610
2011-10-15 19:43:41ezio.melottisetnosy: + ezio.melotti
2011-10-15 15:09:08alonhosetfiles: + 7317.patch

messages: + msg145593
2011-10-15 12:28:18oddthinkingsetmessages: + msg145589
2011-10-15 11:05:43alonhosetfiles: + 7317.patch

nosy: + alonho
messages: + msg145586

keywords: + patch
2010-11-04 03:41:05oddthinkingsetnosy: + oddthinking
messages: + msg120374
2009-12-01 16:59:43amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg95867
2009-11-13 19:23:34pitroucreate