New submission from Vladimir Feinberg <v...@sisudata.com>:
Python's standard logger provides an exception() method, which is to be called from except blocks to log out exception traces by pulling from sys.exc_info(). Per https://github.com/python/cpython/blob/3.9/Lib/logging/__init__.py#L617 , logger.exception('my message') eventually boils down to something like traceback.print_exception(ei[0], ei[1], ei[2], None, some_buffer) where ei is the sys.exc_info(). However, the traceback code generates that printout by constructing a TracebackException recursively for every `except` context. In turn, if a RecursionError was generated from an exception thrown across many except blocks, the TracebackException construction itself will have a RecursionError. This is particularly bad in cases where you'd want to capture this failure information, such as when you're printing the exception, since you'll never find out about the originating error. Certain (well-used) libraries rely on try/except for control flow, and occasionally do recurse in their except blocks, so such exceptions are not hypothetical. A solution to this might be to avoid constructing a TracebackException, and instead unwind traceback context using a while loop. ---------- components: Library (Lib) files: exc.py messages: 385828 nosy: vlad2 priority: normal severity: normal status: open title: Printing RecursionError results in RecursionError versions: Python 3.6, Python 3.7, Python 3.9 Added file: https://bugs.python.org/file49769/exc.py _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43048> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
