Writing Robust Programs with Error Handling

When a File Assumption Fails

A program that opens a file makes an assumption: the file exists and can be read. That assumption may be wrong. A user might enter a filename that does not exist, or the file might not be accessible. Without error handling, the program can stop with a raw traceback. A try/except structure lets the program catch the failure, explain it clearly, and end or recover in a controlled way.

Two Paths Through try and except

The try block contains the operation that might fail. Here, that operation is open(). If it succeeds, the file object is assigned to fhand, the except block is skipped, and the program continues to its file-processing loop. If open() fails because the file does not exist, it raises FileNotFoundError. Python immediately stops the try block and jumps to the except block instead.

filename = input("Enter a filename: ")

try:
    fhand = open(filename)
except FileNotFoundError:
    print("File cannot be opened: " + filename)
    exit()

for line in fhand:
    if line.startswith("Subject"):
        print(line)

This example follows the file-counting scenario. A successful open assigns fhand, so the later loop can examine the file and count lines beginning with Subject. A failed open sends execution to the except block. The recovery code displays the filename and calls exit(), so the loop does not attempt to use an unopened file.

Successful and Failed Opens

Enter a filename: missing.txt
File cannot be opened: missing.txt

The important control-flow detail is what does not happen: after the failed open, the for loop and its result output never execute. Calling exit() in the except block prevents the program from trying to process a file that was never opened.

From Traceback to Helpful Feedback

A raw Python traceback contains technical details, but it may confuse a user who only needs to know what went wrong. The except block gives the program control over its response. A message such as File cannot be opened: missing.txt identifies the failed action and the filename involved. That is more useful feedback than leaving the user with an unhandled traceback.

Mistakes That Break Recovery

• Opening the file without a try/except structure

  If the file does not exist or cannot be accessed, the operation fails without recovery code and the program displays a raw traceback.

  Fix: Place the open() call inside a try block and handle the failure in an except block.

• Printing a message but continuing to the file-processing loop

  The program may attempt to use fhand even though the file-opening operation failed.

  Fix: For this critical operation, call exit() in the except block after displaying the message.

• Showing only a raw technical error to the user

  The traceback contains internal technical details and does not clearly guide the user.

  Fix: Print a user-friendly message that explains the failure and includes the filename the user tried to open.

Practice the Control Flow

1. A robust file-reading program treats open() as a possible failure point. The try block contains the operation, and the except block handles a failure such as FileNotFoundError. If opening succeeds, the program continues with the file object. If opening fails, the program gives the user a meaningful message and calls exit() before later file-processing code can run.