Debugging exceptions


#1

If my Python code has an error, I get a message like this on the console:

[Thread 1 exited with exception ValueError @[0015:038A:0000:0000:0000:0000:0000:0000]](javascript:window.except('@[0015:038A:0000:0000:0000:0000:0000:0000]','Thread 1 exited with exception ValueError '))
 ets Jan  8 2013,rst cause:2, boot mode:(3,6)
load 0x40100000, len 32524, room 16 
tail 12
chksum 0x97
ho 0 tail 12 room 4
load 0x3ffe8000, len 2276, room 12 
tail 8
chksum 0xae
load 0x3ffe88f0, len 7672, room 0 
tail 8
chksum 0x2a
csum 0x2a

Is there some way to associate that with a line number or something in the code? Adding a bunch of prints to narrow down the offending line is tedious.


#2

Is the first line red in the serial monitor? Can you click on it?

Zerynth Studio tries to trace back to the line that generated that error.


#3

Ah, that works. Off by a line or two, and possibly inside a built-in function with no traceback to the caller, but much better than nothing. Thanks.

Even knowing about that feature, I still can’t find any reference to it in the docs.

Is there any documentation on the serial communication between VM and console app? There’s obviously more going on than just “streams.serial()” directing “print” output to the serial port, and maybe having more info about that interface would help with the problem I’m having on wakeup after STANDBY sleep mode (Go_to_sleep on esp8266).


#4

There is a small reference here:

“When an exception is printed, the error message is concatenated with the error code and, if the exception has been raised, with the bytecode position where the error happened.”

from https://docs.zerynth.com/latest/official/core.zerynth.stdlib/docs/official_core.zerynth.stdlib___builtins__.html

That’s incorrect. The serial communication it’s just what you expect. Zerynth Studio is able to recognize the format of an exception and doing a traceback from the bytecode address to the line of code that’s raising the exception (or somewhere near).

What you see in the serial monitor though, it’s really just a string in the form @[0015:038A:0000:0000:0000:0000:0000:0000]].

I hope this helps you better understand how it works, and easier developing :slight_smile:

About your other thread for the ESP8266 sleep mode, I’ll reply as soon as I have some more informations.


#5

OK, I did find the reference about bytecode position, but it would be worth mentioning, either there or in the section on the serial console, that the GUI is smart enough to convert that back to a source line. Thanks for the details.