Micropython TypeError messages contain almost no useful information

[Quadrangle]

Using micropython 1.24 on an ESP-32, we got a TypeError message after heavily refactoring a fairly large project.

One time the message vaguely mentioned that some arguments of str and int were wrong. No function name, no line number.

After fixing that, we got a TypeError message that indicated a function takes 2 arguments but was given 3. No function name. No line number.

How was it decided mentioning the name of the function or where it was called from was unnecessary? Even just the module name would have been very helpful.

Are there any solutions other than exhaustive code inspection? Perhaps, try to "run" each module individually? Add a try catch block around everything?

This is infuriating. Imagine running a spell check on a huge document and the result was a message: "something in here is spelled incorrectly."

[GitHubsSilverBullet]

Must be an ESP thing…

[Quadrangle]

Have you or anyone ever seen a TypeError on a platform other than ESP32, and line number information appeared in the message? Sent from Yahoo Mail for iPad On Tuesday, November 5, 2024, 8:40 AM, Norbert ***@***.***> wrote: screen.png (view on web) Must be an ESP thing… — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[stinos]

Have you or anyone ever seen a TypeError on a platform other than ESP32, and line number information appeared in the message?

No, never, because the exception message itself never contains file or line number (unless it's something custom). Only the stacktrace does. So is your problem perhaps that you're not printing out the full stacktrace somewhere, but only the message? I.e.

import sys


def fun():
    raise TypeError("oops")


try:
    fun()
except Exception as e:
    print("without stacktrace:", e)
    print("\nhere comes the stacktrace:")
    sys.print_exception(e, sys.stdout)

outputs

without stacktrace: oops

here comes the stacktrace:
Traceback (most recent call last):
  File "foo.py", line 9, in <module>
  File "foo.py", line 5, in fun
TypeError: oops

[GitHubsSilverBullet]

[ricksorensen]

FYI: summary- both rp2 and esp32s3 have similar error messages, and with undefined variable arg or too many args the line/function name reference is not very precise.

file `tq.py' copied to an esp32s3 and a rp2040:

print("use a line up")     # to get function defined at line3

def q(a,b):
    return a/b

Running on RP2040 (with mpremote):

MPY: soft reboot
MicroPython v1.24.0-preview.462.g078ead24f on 2024-10-23; XIAO RP2040 Local with RP2040
Type "help()" for more information.
>>> import tq
use a line up
>>> tq.q(1,2)
0.5
>>> tq.q(1,0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "tq.py", line 4, in q
ZeroDivisionError: divide by zero
>>> tq.q(1,[0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "tq.py", line 4, in q
TypeError: unsupported types for __truediv__: 'int', 'list'
>>> tq.q(a,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' isn't defined
>>> tq.q(1,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes 2 positional arguments but 3 were given
>>> 

Running on ESP32S3 (with mpremote):

MPY: soft reboot
MicroPython d34b15ac6-dirty on 2024-11-04; TinyS3 with ESP32-S3-FN8
Type "help()" for more information.
>>> import tq
use a line up
>>> tq.q(1,2)
0.5
>>> tq.q(1,0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "tq.py", line 4, in q
ZeroDivisionError: divide by zero
>>> tq.q(1,[0])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "tq.py", line 4, in q
TypeError: unsupported types for __truediv__: 'int', 'list'
>>> tq.q(a,1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'a' isn't defined
>>> tq.q(1,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: function takes 2 positional arguments but 3 were given
>>>

[Josverl]

Another possibility: A lot of debug info is removed when cross compiling or freezing modules with -O3

It saves space at the cost of clarity.

[bixb922]

Have you or anyone ever seen a TypeError on a platform other than ESP32, and line number information appeared in the message?

I always get the line number and function name even with fairly large programs (>20 modules, >6500 lines). For example:

def q(a,b):
	return a/b

q(1,2)
q([1,2,3],[4,6,7])

The output looks like this:

MicroPython v1.24.0-preview.476.g18c9abc32 on 2024-10-24; Raspberry Pi Pico with RP2040
Type "help()" for more information.
>>> import type_error
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "type_error.py", line 5, in <module>
  File "type_error.py", line 2, in q
TypeError: unsupported types for __truediv__: 'list', 'list'

I see the same result on ESP32, ESP32-S3 and RP2040 with MicroPython 1.24 and 1.23 at least and remember seeing that with previous versions too.

When the main program is executed with the mpremote run command, the module name is always <module>, but line numbers and function names are always correct. When the error occurs while in the REPL, the input file name is <stdin>.

If I trap the exception with try/except, to print the traceback I need to call sys.print_exception(e, sys.stdout)as pointed out above by @stinos.