Files and Exceptions

Two things every real program eventually needs: reading and writing data that outlives the program itself, and handling the moments when something goes wrong.

Reading and writing files. On a normal computer, open("data.txt", "w") opens a file for writing (creating it if needed), and calling .write(text) on the result sends text into it; open("data.txt", "r") opens it for reading, and .read() or looping over the file line by line pulls the text back out. Files should generally be closed once you're done — usually with a with open(...) as f: block, which closes the file automatically even if an error happens inside it.

Simulating files in this sandbox. This lesson's runner executes Python in a sandboxed environment with no persistent disk, so it can't open real files on your computer. To still practice the behavior of file I/O, the examples below use io.StringIO, a built-in class that behaves like an open file but stores its contents in memory instead of on disk. Everything you do with it — .write(), reading lines, .seek(0) to "rewind" back to the start before reading — mirrors what you'd do with a real file object; only the storage location differs.

Exceptions. When something goes wrong at runtime — converting text that isn't a number, dividing by zero, looking up a key that doesn't exist — Python raises an exception, which stops the program unless something catches it. A try/except block lets you catch a specific exception type and recover instead of crashing:

try:
    value = int(user_input)
except ValueError as error:
    print("That wasn't a number:", error)

Catching a specific exception type (like ValueError) rather than a bare except: is important — a bare except silently swallows every kind of error, including ones you never anticipated and would rather see fail loudly.

finally. An optional finally block runs no matter what happened in the try — whether it succeeded, raised a handled exception, or even raised one that wasn't caught. It's the natural place for cleanup that must always happen, such as closing a file or a network connection.

raise. You can trigger your own exception with raise, typically to reject invalid input to a function before it causes confusing behavior further down the line: raise ValueError("age cannot be negative"). Combined with a descriptive message, this makes bugs far easier to track down than letting invalid data silently propagate and fail somewhere unrelated.

Together, file I/O and exception handling are what let a program interact with the messy outside world — user input, other systems, files — without falling over the first time something isn't exactly as expected.