python glitch

[kjm]

I think I've stumbled across a python glitch in 1.20.1.r1

If I make a syntax error like so

try:
  printr ('something') 
except: print ('exception caught')

I get the expected result

exception caught

But if I make the syntax error anywhere else

try:
  print r('something') 
except: print ('exception caught')

or

try:
  print ('something'r) 
except: print ('exception caught')

or

try:
  print ('something')r
except: print ('exception caught')

The exception doesn't catch it & my program stops

Traceback (most recent call last):
  File "<stdin>", line 3
SyntaxError: invalid syntax

Am I missing something here? If so what? If not how do we get this fixed?

[robert-hh]

@kjm I would not see that as a principal glitch: There is a difference between your first and the other examples:
The first example contains proper python syntax. It raises a runtime error because the function printr() was not defined. That will be caught by the try/except clause.
The other examples have syntax errors, which are caught by the parser. CPython behaves similar. When entering code in the REPL, it just differs in the very moment when the syntax error is flagged.
You can get it caught by try/except by putting the wrong syntax into an exec() call, e.g.:

try:
  exec("print r('something')")
except: print ('exception caught')

[kjm]

@robert-hh Awed by your knowledge Rob. Is it only syntax errors that are dealt with by the parser instead of exception? My worry is there could be other errors (mainly OSErrors related to the lte modem) that except could miss as well.

[robert-hh]

@kjm That depends on the implementation, which has to decide whether:

a) it returns an error code to the caller
b) raises an exception
c) simply crashes with a core dump

The distinction between a) and b) is somewhat of a grey area. If a out-of-band situation happens regularly, like uart.read() returning None, when there is no data, then option a) is preferred. Raising an exception is the Pythonic way of error handling, and that is used for more rare errors, or to handle a series of possible errors in one block. Option c) is obviously to be avoided, but happens if there is no other choice, typically as result from bugs in the firmware itself.
From what I have seen, errors when using the LTE modem fall into the a) of b) variants. You have to look into the respective API calls to tell. For LTE, the Sequans firmware of the modem may silently fail, whith no proper signalling to the Pycom firmware. That seems to happen sometimes.

[kjm]

@robert-hh Interesting. The GPY modem gets itself into a state where it says it's connected but can't run data. Trying to disconnect it to reset it gives an OSError so I do a machine.reset(). Can you suggest any tricks to maybe restore the modem without a machine.reset()?