Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!bawden.eternal-september.org!.POSTED!not-for-mail
From: Alan Bawden <alan@csail.mit.edu>
Newsgroups: comp.lang.python
Subject: Re: how to discover what values produced an exception?
Date: Fri, 03 May 2024 19:29:43 -0400
Organization: ITS Preservation Society
Lines: 47
Message-ID: <86r0eimq3c.fsf@williamsburg.bawden.org>
References: <8734qz9ey0.fsf@tudado.org>
	<918e3522-03e0-40e7-928d-bbf87698a7b3@tompassin.net>
	<mailman.4.1714772954.3326.python-list@python.org>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sat, 04 May 2024 01:29:46 +0200 (CEST)
Injection-Info: bawden.eternal-september.org; posting-host="bb54c05ff7b658c943be99c1f787e152";
	logging-data="859898"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+H3YrnwGM/87n4HTg5kzuT"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux)
Cancel-Lock: sha1:oL1NGID4D1FzGdk3G+mb+hLbUIQ=
	sha1:7FizeFR5qFkdpz2R/vL+BWYO1QU=
Bytes: 3197

Thomas Passin <list1@tompassin.net> writes:

   On 5/3/2024 9:56 AM, Johanne Fairchild via Python-list wrote:
   > How to discover what values produced an exception?  Or perhaps---why
   > doesn't the Python traceback show the values involved in the TypeError?
   > For instance:
   >
   > --8<-------------------------------------------------------->8---
   >>>> (0,0) < 4
   > Traceback (most recent call last):
   >    File "<stdin>", line 1, in <module>
   > TypeError: '<' not supported between instances of 'tuple' and 'int'
   > --8<-------------------------------------------------------->8---
   >
   > It could have said something like:
   >
   > --8<-------------------------------------------------------->8---
   > TypeError: '<' not supported between instances of 'tuple' and 'int'
   >    in (0,0) < 4.
   > --8<-------------------------------------------------------->8---
   >
   > We would know which were the values that caused the problem, which would
   > be very helpful.

   In this example it would not help at all to know the actual values. Knowing
   that you are trying to compare incomparable types is enough.

In general, it absolutely can help.  The programmer can sometimes
recognize where a value of unexpected type came from just by looking at
it, allowing her to quickly deduce just what went wrong without further
investigation.

A good error message shouldn't withhold any information that can
_easily_ be included.  Debugging is more art than science, so there is
no real way to predict what information might prove useful in solving
the crime.  I emphasized "easily" because of course you have to draw the
line somewhere.

The fact that Python error messages often fail to mention the actual
objects that caused the error has always annoyed me.  I've always
presumed that for some reason it just wasn't easy to do.  And it's never
been more than a minor annoyance to me.

So the OP is not wrong for wishing for this.  Other programming
languages do it.  Other Python programmers miss it.

- Alan