Joe Wells <bugs-python-...@jbw.link> added the comment: In the hopes of convincing someone to install a fix to this bug, I will mention a few additional points.
When I mention “the capture_locals feature”, I mean calls of the form traceback.TracebackException(..., capture_locals=True) and traceback.StackSummary.extract(..., capture_locals=True). 1. Right now, the capture_locals feature is unreliable. If any frame on the entire stack has a single local variable for which repr raises an exception, the user gets no information whatsoever back for the entire stack except for that exception, and that exception does not identify the offending stack frame or local variable. Also, every use of the capture_locals feature must be inside a try-except statement. 2. The exceptions raised by the capture_locals feature will often be junk exceptions carrying no useful information. The meaning of these exceptions will often be “there is an incompletely initialized object in a variable somewhere on the stack”. Because this is a fairly normal state of affairs, this will often not be useful information. 3. Although it is a excellent idea to encourage Python coders to ensure that __repr__ method never raise exceptions, it seems unlikely this will cause many __repr__ methods to be fixed in the near future. My impression is that __repr__ methods that raise exceptions on incompletely initialized objects are common. One reason for this might be that authors of __repr__ methods rarely suffer from this problem personally, because they will generally supply correct arguments to their own class constructors, and even when they don't (e.g., while building unit tests), they are unlikely to try to format to strings all the local variable values on the stack in the exception traceback. 4. Right now, the caller of traceback.FrameSummary(..., locals=x) needs to go through the entire dict x and for every value v in x test whether repr(v) raises an exception and if so either remove the key/value pair or change the value to something which can be safely repr-ed. Then FrameSummary.__init__ will repeat this work and run repr on every value in x again. So using FrameSummary safely requires duplicating the work, i.e., running repr on every value in the dict both before and during the call to FrameSummary. 5. Anyone who is using the capture_locals feature on an exception traceback has already caught an exception, and therefore decided not to let that exception “bubble up”. Their attempts to log or otherwise cope with the exception will be spoiled by the capture_locals feature raising an unrelated exception. This is even worse when the exception raised by the capture_locals feature is a junk exception that merely indicates there is an incompletely initialized object on the stack. This is likely to happen because exceptions will often happen during the initialization of an object. 6. The most recent suggested fix does in fact report the extra repr exception discovered by the capture_locals feature in the string that represents the local variable's value. The main effect of the current code propagating this repr exception is to make it harder to deal with the original exception. I hope these points are useful. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43656> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
