NAESER’S LAW: You can make it foolproof, but you can’t make it damnfoolproof.
A program rarely works as expected, at least on the first try. Traditionally a programmer would choose between one of these two strate-
gies when faced with runtime program errors. The problem is ignored or each condition is verified where an error may occur and then he or she would write code in consequence. The first option which is very popular is not advisable if we want our program to be used by anyone besides ourselves. The second option which is also known as LBYL (Look Before You Leap), is time consuming and may make code unreadable. Let’s have a look at an example of each strategy. The following program reads a file (myfile.csv) separated by tabs and
looks for a number that is found in the first column of the first line. This value is multiplied by 0.2 and that result is written to another file (otherfile.csv). This version does not check for any types of errors and limits itself to its