[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Irit Katriel]

Irit Katriel  added the comment:

This was created about 10 years ago, I wonder if people still feel there is a 
need to change something here, or did we all get used to the status quo by now?

In particular, the suggestion is to indicate that the traceback of chained 
exceptions is truncated.

--
nosy: +iritkatriel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Irit Katriel]

Change by Irit Katriel :


--
versions: +Python 3.10, Python 3.9 -Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Raymond Hettinger]

Changes by Raymond Hettinger raymond.hettin...@gmail.com:


--
nosy: +rhettinger

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Nick Coghlan]

Nick Coghlan added the comment:

Marking this as Library as well, since the traceback module should also be 
updated.

--
components: +Library (Lib)

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Ezio Melotti]

Changes by Ezio Melotti ezio.melo...@gmail.com:


--
nosy: +ezio.melotti

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Martin Morrison]

Changes by Martin Morrison m...@ensoft.co.uk:


--
nosy: +isoschiz

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Terry J. Reedy]

Changes by Terry J. Reedy tjre...@udel.edu:


--
type: behavior - enhancement
versions: +Python 3.4 -Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

I've thought of a different approach to this which should be less hazardous to 
doctests: include the truncation warning in the *traceback* section, rather 
than in the header. doctests already ignore the details of that section because 
checking it is too fragile.

cc'ing Georg because I think this a potentially big win for the usability of 
chained tracebacks, but also think it is dubious from a feature vs fix point of 
view.

With the change I'm considering, truncated tracebacks would look something like:

Traceback (most recent call last):
  truncated: another exception occurred
  File /home/rdmurray/python/email6/Lib/email/message.py, line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/rdmurray/python/email6/Lib/mailbox.py, line 1631, in set_flags
self.replace_header('Status', status_flags)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 495, in 
replace_header
print('rep', self.header_factory)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'

--
nosy: +georg.brandl

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Éric Araujo]

Changes by Éric Araujo mer...@netwok.org:


--
nosy: +eric.araujo

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

The redundancy of the (most recent call last) when there's only one frame in 
the stack is a separate problem (as it happens even for unchained tracebacks), 
but feel free to create a new issue if you'd like to see it changed (I expect 
it would needlessly break doctests, so I don't like your chances of getting 
agreement on it, though)

+1 for the short and to the point Truncated traceback phrasing in the header 
line to address the current issue, though.

I've removed 3.2 from the affected releases due to the same may break 
doctests concern (error handling doctests are so inherently fragile that I 
don't mind breaking cases like this in a major version upgrade)

--
versions:  -Python 3.2

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Terry J. Reedy]

Terry J. Reedy tjre...@udel.edu added the comment:

I agree with Nick's rationale for the current order, and also like his idea of 
indicating that the first traceback is truncated (which has not been completely 
obvious to me). Bike-shedding a bit, I would prefer something more like:

Truncated traceback of caught exception:

The '(most recent call last)' bit is nonsensical when only the most recent call 
is given.

--
nosy: +terry.reedy

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Nick Coghlan]

Nick Coghlan ncogh...@gmail.com added the comment:

The ordering is as it is so that the last line in the displayed traceback 
corresponds to the exception that was actually caught. That is, the last line 
remains the same regardless of whether or not there was an earlier exception in 
the chain. Without that, the caught exception would be buried in the middle of 
a wall of text:

Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/rdmurray/python/email6/Lib/mailbox.py, line 1631, in set_flags
self.replace_header('Status', status_flags)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 495, in 
replace_header
print('rep', self.header_factory)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'
CAUGHT THIS
This exception was caught while handling:
Traceback (most recent call last):
  File /home/rdmurray/python/email6/Lib/email/message.py, line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'
NOT THIS

The consequence is that the outermost call in the call stack ends up buried in 
the middle of a wall of text instead. That's not optimal either, but we have to 
choose one or the other and I think the status quo is the better choice.

However, not closing this yet, as I think RDM may have a valid point: should we 
put something at the *start* of the truncated traceback to indicate that it was 
cut short due to another exception? For example:

Traceback (truncated due to later exception, most recent call last):
  File /home/rdmurray/python/email6/Lib/email/message.py, line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/rdmurray/python/email6/Lib/mailbox.py, line 1631, in set_flags
self.replace_header('Status', status_flags)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 495, in 
replace_header
print('rep', self.header_factory)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[R. David Murray]

New submission from R. David Murray rdmur...@bitdance.com:

Consider the following traceback:

Traceback (most recent call last):
  File /home/rdmurray/python/email6/Lib/email/message.py, line 466, in 
__getattr__
return getattr(self._headers, key)
AttributeError: '_Header_List' object has no attribute 'header_factory'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File stdin, line 1, in module
  File /home/rdmurray/python/email6/Lib/mailbox.py, line 1631, in set_flags
self.replace_header('Status', status_flags)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 495, in 
replace_header
print('rep', self.header_factory)
  File /home/rdmurray/python/email6/Lib/email/message.py, line 469, in 
__getattr__
self.__class__.__name__, key))
AttributeError: 'mboxMessage' object has no attribute 'header_factory'


The first traceback, which is supposed to be the primary error, gives
no indication of where the problem occured.  It starts with a fairly
deeply nested call.  The second traceback does show the line where the
error occured in the except statement, but you have to read the lines
above it to find the line that actually triggered the original
traceback.

I think it would be much better if either the full traceback were
given for the first traceback, or for both of them.  I realize
that the short traceback for the first traceback is how things
have traditionally worked when exceptions are caught, but as
evidenced by issue 1553375 this is often not the desired behavior
even before the existence of chained exceptions.

--
components: Interpreter Core
messages: 140153
nosy: r.david.murray
priority: normal
severity: normal
status: open
title: Chained tracebacks are confusing because the first traceback is minimal
type: behavior
versions: Python 3.2, Python 3.3

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Eric Snow]

Changes by Eric Snow ericsnowcurren...@gmail.com:


--
nosy: +ericsnow

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

I think the reason the chained tracebacks look backward to me is twofold: I'm 
used to the last one in the list being the *only* one I get (in python2), and 
the last one in the list is often the one I want to deal with first.  This is 
especially true if my try/except is transforming the 
more-specific-but-not-application-meaningful exception into one that is 
meaningful for the application.

So another possibility would be to reverse the order in which the tracebacks 
are printed, and instead of saying during the handling of the above 
exception..., we'd say this exception occurred during the handling of the 
following exception:.  Doing this would probably greatly reduce the desire for 
a way to suppress the traceback chaining.

--
nosy: +ncoghlan

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[Benjamin Peterson]

Benjamin Peterson benja...@python.org added the comment:

There _is_ no full traceback for the first exception. It stops as soon as it's 
handled.

--
nosy: +benjamin.peterson

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12535] Chained tracebacks are confusing because the first traceback is minimal

[R. David Murray]

R. David Murray rdmur...@bitdance.com added the comment:

One can argue that it is necessary to read the traceback in reverse order, so 
that reading the chain in reverse order is a logical extension of that.  So I 
guess I have no serious objection to this being rejected.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12535
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com