Srijan R. Shetty bio photo

Srijan R. Shetty

Email Twitter LinkedIn Github RSS

So, what you might ask? In fact you might have seen this blasphemy time and time again:

    # Some code
except Exception as e:

Or this variation written by another apostate (me, a few days ago):

    # Some code

While we may be blinded in the present, at some point your future-self will want to travel back in time and smack you for your idiocy, like I wanted to, for this mea cupla.

The fundamental issue with bare excepts as they’re called in idiomatic python is, - as mentioned earlier - these gremlins come back and bite you.

While trying to automate file uploads from my laptop to a cloud storage, I had a rogue IO function which once, stalled indefinitely. Since I was uploading multiple files in sequence, this would halt the entire program; (yes, I could use threads but that discussion is best left for another day). Since this was all wrapped up in a busy loop which watched for changes, I was okay with one off failures. In an attempt to tame the function I decided to use SIGALRM and this is when my foolishness dawned upon me.

import signal
import time

class ProcessTimeoutException(Exception):

def timeout():
    raise ProcessTimeoutException()

def db_call():
    except Exception as e:
        print("I'm going to eat the error")

def main():
    signal.signal(signal.SIGALRM, lambda x, y: timeout())

    except ProcessTimeoutException as e:
        print('Never reaches')

if __name__ == "__main__":

Can you notice what’s wrong with the above snippet? db_call ends up eating all exceptions, which renders my timeout logic ineffective.

The solution, you ask? Well, there’s little that we can do without using threads or a monitor process which kills this script when it notices there’s no progress (the monitor in turn ascertain progress using the OS or IPC flags).

So, as a favour to your future self, kindly avoid going bare (with exceptions).