Just when it looked like things were going so well, there was a problem in the Head-Ex storeroom.

A trainee was recording the consignment of cheese when there was a problem that prevented the program from recording the delivery. That meant the cheese was never assigned to a delivery truck. So the cheese never left the storeroom and it just sat there for a very long time. And that meant—well, you can just imagine...

To prevent the same thing happening again, you need to find what caused the problem.

It turns out the whole thing was caused when someone from Technical Support decided to change the permissions on the deliveries.txt file, making it read-only. When the system tried to write deliveries into the file, it failed. But what’s worse, it failed silently:

When you were writing programs that ran in the Python Shell, you could always tell when it failed: a huge, ugly error message appeared. Why not with GUIs? Don’t they do the same?

They do, but the trouble is that the message appears in the Shell and your user is busy looking at the nice GUI, so the ugly error can often be missed.

When using a GUI, how do you spot errors? Once spotted, what happens then?

What happens when an error occurs? Some errors are really bad: they cause the program to crash. Other, less serious errors are known as recoverable: the program can keep running, even though something went wrong. You can spot these situations in your code, because most programming technologies throw an exception when they occur.

Imagine a line of code that has a problem, such as the line that was trying to write to the deliveries.txt file. Python will spot that the append operation failed and, instead of running the rest of the code that follows, Python abandons ship and skips out of the code completely. That’s what throwing an exception means: the program doesn’t crash, but it abandons what you were trying to do and tries to recover the situation:

But why skip past the rest of the code? Why not keep on running? Generally, that would be a bad idea. Once a line of code has gone bad, there’s no way of knowing if it makes sense to keep running the code that follows. For example, if the Head-Ex code can’t open the deliveries file to append to it, it makes no sense to continue trying to write data to the unopened file!

In order to recover, you need to start running your code from somewhere else.

Python spots when an exception is thrown, and you can write some code to run when the exception occurs. This is called catching the exception. The code that you run when there’s an error resulting in the thrown exception is called an exception handler.

Creating exception handlers can really make life easy for your users. Instead of a flaky program that crashes or fails silently the first time something weird happens, you can write programs that gracefully recover from errors. Exception handlers tidy up when something goes wrong and can even let your user know that something strange happened.

That’s what you need here: an exception handler that tells the user when there’s a problem writing a delivery to the file.

How are exception handlers written in Python?

In order to recover from an error as it happens, you need to indicate the code that might throw an exception. In Python, you do this with try and except.

All you need to do is take the piece of potentially troublesome code and add the try and except labels:

If an exception is thrown between the try and except labels, the code that follows the except label runs. The code that threw the exception is abandoned. If no exception occurs, the code runs normally and the code that comes after the except label is ignored.

Notice that the try/except labels are wrapped around all of the function’s code. If there’s a problem opening the deliveries.txt file, you don’t ever want to try writing to it. So, when trouble strikes, you should adandon ship and skip to the code that tries to recover from the error.

The code that then runs is the exception handler.

Exception Magnets

Assemble the code to handle an exception in the save_data() function. The exception handler needs to display the details of the exception in the title bar of the window. Note: remember to indent the code in the exception handler, in addition to the code in the try block.

fileD = open("deliveries.txt", "a")
fileD.write("Depot:
")
fileD.write("%s
" % depot.get())
fileD.write("Description:
")
fileD.write("%s
" % description.get())
fileD.write("Address:
")
fileD.write("%s
" % address.get("1.0", END))
depot.set("")
description.delete(0, END)
address.delete("1.0", END)

Exception Magnets Solution

You were asked to assemble the code to handle an exception in the save_data() function. The exception handler needs to display the details of the exception in the title bar of the window. You needed to remember to indent the code in the exception handler, in addition to the code in the try block.

Test Drive

Let’s see if the code works. Make sure the deliveries.txt file is read-only. Then run the new version of the program in IDLE and try to record a delivery by clicking on the Save button.

Sure enough, when you try to save the delivery details, the program catches the exception and the exception handler displays the error message in the window title.

Wonder what the people at Head-Ex will think of this?

You do a quick demo for the folks at Head-Ex and, even though the program works, it’s not quite what they need.

The error message is more visible than when it was appearing in the Python Shell, but it isn’t a whole lot more visible. Sure, you’ve proved that you can spot when an error happens and then run an exception handler in order to do something about the error. But you really need to do something that will interrupt the user and highlight the situation. You need something that will force the user to acknowledge the error before he continues doing something else.

A GUI message box might do the trick.

Most of the time, GUI programs put the user in charge. If the user chooses to click a button or edit a field, the computer lets them do just that in whatever order and at whatever time the user chooses. But sometimes, GUI programs need to stop the user and ask her a question, getting her to confirm or acknowledge something. That’s where message boxes come in.

A message box is something that requires a response, which is why it’s sometimes called a dialog box.

The simplest message box displays a message with a single OK button:

A message box always displays the message in a separate window, typically in front of your main GUI window. And it won’t go away until you click it, dismissing it. That’s why message boxes are the most commonly used way of displaying errors. The user has to read and respond to the error before continuing.

You should be sparing in how often you display message boxes, because if users see too many of them, they are likely to click them without reading the message. But, when used carefully, they keep your user informed and alert.

All of the message box code is contained within a tkinter module called messagebox, so the first thing to do is import the module:

import tkinter.messagebox

Then, you’re good to go. Within the messagebox module, there’s a whole bunch of different dialogs to choose from. But all of them fall into two main categories.

Message boxes that say stuff

To display a simple message on the screen, you might display a message box like this:

Message boxes that ask stuff

If you need a message box that asks the users a question, you will need to check the return value to see what they chose:

When tkinter gets to this line, it will wait for the user to answer the question and then assign True (yes), False (no), or None (cancel) to the response variable.

Let’s see what other message boxes are available.

Who Does What?

These are the message boxes available in tkinter. Think carefully about each of the following examples. We know which we’d use at Head First Labs. Which type of box on the left would you choose for each of the messages on the right? Connect the messages to the boxes with lines.

showinfo	“OK to fire boosters?”
showwarning	“Your tartan clogs have arrived.”
showerror	“Seriously, I think he’s just ignoring the phone.”
askquestion	“Danger, Will Robinson!”
askokcancel	“Do you want fries with that?”
askyesnocancel	“Dude, the printer’s busted.”
askretrycancel	“So, you want Nutella on your bacon and jelly sandwich?”

Who Does What? Solution

These are the message boxes available in tkinter. You were to think carefully about each of the following examples, then indicate which type of box on the left you would choose for each of the messages on the right. You were to connect the messages to the boxes with lines.

Sharpen your pencil

The folks at Head-Ex want your program to display this message box if there’s a problem saving a record to the deliveries.txt file:

from tkinter import *
___________________________________________________________________

def save_data():
    try:
        fileD = open("deliveries.txt", "a")
        fileD.write("Depot:
")
        fileD.write("%s
" % depot.get())
        fileD.write("Description:
")
        fileD.write("%s
" % description.get())
        fileD.write("Address:
")
        fileD.write("%s
" % address.get("1.0", END))
        depot.set("")
        description.delete(0, END)
        address.delete("1.0", END)
    except Exception as ex:
___________________________________________________________________

Sharpen your pencil Solution

The folks at Head-Ex want your program to display this message box if there’s a problem saving a record to the deliveries.txt file:

Complete the missing lines in this section of your program to create the message box.

Hint: You need to include a newline in the message box text.

Test Drive

Now what happens if you try to save a record when the deliveries.txt file is read-only?

Great! The exception handler displays an error message with an icon that really alerts the user to the problem. Let’s check back with Head-Ex to see if they like it.

The error message box was exactly what Head-Ex needed.

By catching exceptions and displaying important information in message boxes, you can greatly improve the experience of your users when things go wrong.

Great work!

You’ve got Chapter 9 under your belt. Let’s look back at what you’ve learned in this chapter: