[Tutor] try..except - what about that ton of **Error statements?

[Steven D'Aprano]

On 23/05/13 02:09, boB Stepp wrote:

> I would like to ask some general questions here. Problems can arise
> from bugs in the operating system, bugs in the programming language(s)
> being used, bugs in packages/modules being used, bugs in any third
> party packages being used, etc. Also, whenever any one of these things
> is updated/upgraded, it can introduce new issues. What strategies can
> one use to deal with these possibilities that seem entirely out of the
> programmer's control?


They're not really out of your control though. You can always write code
to work around them.

For instance, a long time ago I was using a programming language that had a bug that caused the program to crash if you tried to display the string "0^0". If this was Python, I might do something like this:

def my_print(astring):
     if astring == '0^0':
         # Avoid the system bug.
         astring = '0 ^ 0'  # Close enough...
     print astring


and then make sure I always call my_print instead of print directly.

Sometimes it is sufficient to just avoid triggering the bug. Sometimes you might need use a different tool. For instance, in Python, print is not "thread safe" -- if you have two different threads trying to print at the same time, their output may interleave.

# Thread 1:
print "Hello world!"

# Thread 2:
print "Goodbye cruel world :-("

# Output might look like this:
HelGoodblo ye crue l worworldld :-(!



Is this a bug in print? No, not really, but it is a limitation, it is not designed to be thread safe. So when using threads, you can:

- always make sure only one thread is responsible for doing any printing;

- if you must have multiple threads printing at the same time, use sys.stdout.write instead of print, because it is thread-safe.


So working around bugs is, in general, possible, even if sometimes it is hard.

A general technique when programming is to always have a good, solid test suite. This will detect any change in behaviour, whether due to your own programming errors, on bugs in the language or operating system. What you do is as you develop your own code, in parallel you also develop a second program that tests as much of your code as you can.

For instance, suppose you have a (trivial) function that doubles a number and adds one:

def double_plus_one(x):
     return 2*x + 1

So you have a second file open that tests it:


from my_app import *

def test_double_plus_one():
     assert double_plus_one(5) == 11
     assert double_plus_one(100.25) == 201.5
     assert double_plus_one(-0.5) == 0


test_double_plus_one()



(Or you can use a test frame work like unittest or doctest or both.) Now, whenever you change something, say you upgrade to a new version of the language, or change your code, you run the test file and see what tests start failing. Each failed test indicates a bug that needs to be fixed, although it doesn't tell you what introduced the bug.



-- 
Steven