Skip to content

Display full tracebacks when an error occurs asynchronously #51566

Closed
Closed
Display full tracebacks when an error occurs asynchronously#51566
Labels
interpreter-core(Objects, Python, Grammar, and Parser dirs)stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

Description

@pitrou
pitrou
opened on Nov 13, 2009
BPO 7317
Nosy @amauryfa, @pitrou, @ezio-melotti, @asvetlov, @vadmium
Files
  • 7317.patch
  • 7317.patch
  • issue7317.diff
    		•

    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 2012-11-03.14:48:02.931>
created_at = <Date 2009-11-13.19:23:34.055>
labels = ['interpreter-core', 'type-feature', 'library']
title = 'Display full tracebacks when an error occurs asynchronously'
updated_at = <Date 2012-11-03.14:48:02.930>
user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2012-11-03.14:48:02.930>
actor = 'asvetlov'
assignee = 'none'
closed = True
closed_date = <Date 2012-11-03.14:48:02.931>
closer = 'asvetlov'
components = ['Interpreter Core', 'Library (Lib)']
creation = <Date 2009-11-13.19:23:34.055>
creator = 'pitrou'
dependencies = []
files = ['23413', '23414', '27853']
hgrepos = []
issue_num = 7317
keywords = ['patch', 'needs review']
message_count = 13.0
messages = ['95197', '95867', '120374', '145586', '145589', '145593', '145610', '160465', '167272', '174268', '174616', '174622', '174627']
nosy_count = 9.0
nosy_names = ['amaury.forgeotdarc', 'pitrou', 'ezio.melotti', 'asvetlov', 'oddthinking', 'alonho', 'python-dev', 'martin.panter', 'kachayev']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue7317'
versions = ['Python 3.3']

    Activity

    1. pitrou commented on Nov 13, 2009

      @pitrou
      pitrou
      on Nov 13, 2009
      MemberAuthor

      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 bpo-7060 as an example).

    2. pitrou
      added
      interpreter-core(Objects, Python, Grammar, and Parser dirs)
      stdlibStandard Library Python modules in the Lib/ directory
      type-featureA feature request or enhancement
      on Nov 13, 2009

    3. amauryfa commented on Dec 1, 2009

      @amauryfa
      amauryfa
      on Dec 1, 2009
      Contributor

      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.

    4. oddthinking commented on Nov 4, 2010

      @oddthinking
      oddthinkingmannequin
      on Nov 4, 2010
      Mannequin

      Amaury asks: "Is there an already existing flag that could control this behaviour?"

      I wonder if the warnings module could be used.

    5. alonho commented on Oct 15, 2011

      @alonho
      alonhomannequin
      on Oct 15, 2011
      Mannequin

      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.

    6. oddthinking commented on Oct 15, 2011

      @oddthinking
      oddthinkingmannequin
      on Oct 15, 2011
      Mannequin

      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.

    7. alonho commented on Oct 15, 2011

      @alonho
      alonhomannequin
      on Oct 15, 2011
      Mannequin

      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..

    8. oddthinking commented on Oct 16, 2011

      @oddthinking
      oddthinkingmannequin
      on Oct 16, 2011
      Mannequin

      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.)

    9. alonho commented on May 12, 2012

      @alonho
      alonhomannequin
      on May 12, 2012
      Mannequin

      how does one get his patch reviewed? (it's been 6 months)

    10. pitrou commented on Aug 2, 2012

      @pitrou
      pitrou
      on Aug 2, 2012
      MemberAuthor

      Oops, sorry for the silence, I had forgotten about this issue. I'll take a look at the patch soon.

    11. alonho commented on Oct 31, 2012

      @alonho
      alonhomannequin
      on Oct 31, 2012
      Mannequin

      Hi Antoine, can you please have a look at the patch? It's been over a year since it's submitted. (-: thanks!

    12. kachayev commented on Nov 3, 2012

      @kachayev
      kachayevmannequin
      on Nov 3, 2012
      Mannequin

      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.

    13. python-dev commented on Nov 3, 2012

      @python-dev
      python-devmannequin
      on Nov 3, 2012
      Mannequin

      New changeset a281604a5c9a by Andrew Svetlov in branch 'default':
      Issue bpo-7317: Display full tracebacks when an error occurs asynchronously.
      http://hg.python.org/cpython/rev/a281604a5c9a

    14. asvetlov commented on Nov 3, 2012

      @asvetlov
      asvetlov
      on Nov 3, 2012
      Contributor

      Committed. Thanks, guys!

    15. asvetlov
      closed this as completedon Nov 3, 2012
    16. ezio-melotti
      transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      interpreter-core(Objects, Python, Grammar, and Parser dirs)stdlibStandard Library Python modules in the Lib/ directorytype-featureA feature request or enhancement

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions