Main Content

Insurance against any errors - Volcanoes and Python

Archive - Originally posted on "The Horse's Mouth" - 2011-02-19 20:17:47 - Graham Ellis

Have you heard of people who have taken out insurance, only do discover that they're not covered for some eventuality - "but the list of circumstances doesn't include your flight being canceled because the plane couldn't fly through volcanic ash" is a story that many people heard, with an irony that no-one had even thought of that eventuality before it happened.

There has to be a better way. And in programming, there is!

We have long been encouraged - and I encourage delegates on courses - to check the external environment to their program. That's user inputs to make sure that when a number is asked for, they really have entered a number. It's checking the file system to make sure that a file they have asked to read really does exist. And it's checking that a network connection is alive if you're going to use a network resource. But such checks cannot allow for every eventuality, and something else is needed.

The "fail safe" way of mopping up all fluky errors (and a lot of the standard ones too) is to use an exception - where you write you code along the lines of "try to do X, and if it doesn't work for any reason, do Y to handle the problem. The syntax varies in different languages - in Python, we use the keyword try to preface the code that we want to put in a safety net, and we use the keyword except to specify the code that's to be run if the first block needs to be rescued.

From the Python course, just completed in Frankfurt - applying the net:

  try:
    said = raw_input(pr)
    val = int(said)

And what to do when your user lands in the net and needs a rescue:

  except:
    print "Error - expected a whole number"

The complete source example - which includes a reprompt and further read from the user if an integer is not received -is [here]. The same principle applies in other languages - in Ruby you have a begin and a rescue block. Source example [here]

Note - even with exceptions there can be slightly more to it than just a single safety net. We've chosen in the complete example to reprompt the user which initially you might think is always a good thing to do. However, if the user's input was an end of file, there is no point in trying to read any further - and to do so may even put our program into an infinite loop. So I've added a second except block to my source, and it's first in the source so that it takes precedence - to specifically catch end-of-file conditions and handle them in a different way.