Every program meets bad input and surprises: a word where a number is needed, a zero to divide by, a key that is missing. A program that crashes is a poor program, and a program that hides its errors is a worse one. In this course you learn to read an error message and name the common errors, catch them with try and except so that the program goes on, use else and finally, and build a loop that asks until the user gives a good answer. You learn to raise your own errors with a clear message, and to choose between checking first and catching afterwards. A safe data reader is the project at the end. The practice runs your code on good and bad input and tells you which cases fail.
5 lessons, about 2 h 35 min5 simulations14 problems10 practice questionsPython in every lesson
An error message is not a punishment. It says what went wrong and where. The name of the error is on the last line of the message, and the six to know are ValueError, ZeroDivisionError, IndexError, KeyError, TypeError and NameError. A message of many lines is a traceback, which is read from the bottom: the last line says what, and the lines above show the chain of calls that led to it. A SyntaxError is found before the program runs. A logic fault gives no message at all.
With try and except you say: try these lines, and if this kind of error happens, do this instead. The program does not stop. An except part runs only when an error of the named kind happens, and you can write several, one for each kind, or name two kinds in a tuple. as error gives the error itself. else runs only when there was no error, and finally always runs. Always name the error you expect. A bare except catches every error, including your own typing mistakes, and hides real bugs.
A person may type a letter where you want a number, or an age of minus five. A good program asks again. The recipe has three parts: a while True loop that keeps asking, a try and except that catch a bad conversion, and a break or a return that leaves the loop when the answer is good. A second check handles a good number in a bad range. Put the loop in a function with parameters for the question and the limits, so that it can be used again. On this site, the bad answers go first in the Input box and the good answer last.
Your own code can raise an error with raise, for example raise ValueError with a clear message, when a function gets a value that it cannot use. A function that checks its input and raises a clear error is easier to use than one that fails later with a confusing message. The caller can catch the error with try and except and read the message. An error that nobody catches stops the program with your message. There are two styles of care: look before you leap, which checks first with an if, and try and catch, which uses the error. Choose the first when a simple check exists, and the second when the check is hard, as for a number in text.
In this project we write a safe data reader. Lines of the form name,mark come in from a messy source, with a mark in words, a missing mark, a mark out of range and an empty line. The program keeps the good lines in a dictionary, and reports each bad line with its line number and the reason, instead of stopping. We plan the cases and the expected result by hand, build the reader with try, except and a raised error, test the average of the good data and the list of problems, and extend the reader with a count of the kinds of problem and a limit on the number of problems.
Log in to join the discussion.
Loading…