How to Ignore Python Exceptions with contextlib.suppress()

I used to write a lot of little scripts—some that cleaned up temp files, others that tried to read from a folder that may or may not exist, or opened files I wasn’t entirely sure would be there. And every time, the pattern was the same. Wrap the whole thing in a try-except block, catch something like FileNotFoundError, do nothing in the except, and move on. It worked, but it always felt a bit… heavy for what it was doing.

Then I found contextlib.suppress()—and not from a book or tutorial, but while reading through someone else’s code on GitHub. It’s such a quiet little trick, it almost feels like Python whispering, “You don’t have to write all that out every time.”

This isn’t one of those tools that’ll blow your mind or change the way you think about programming. But it will shave off those tiny repetitive annoyances that clutter up your code more than you realize.

What It Looks Like in Practice

Let’s start basic. Say you want to delete a file, but it might not exist. Here’s what I used to do:

import os

try:
    os.remove("example.txt")
except FileNotFoundError:
    pass

That’s fine. It’s safe. But you’re writing five lines to say “delete this file if it’s there, otherwise ignore it.”

Here’s the same thing using contextlib.suppress():

from contextlib import suppress
import os

with suppress(FileNotFoundError):
    os.remove("example.txt")

Much leaner. Easier to read, too. There’s less mental overhead when scanning the code. I don’t have to ask “what exceptions are we handling here?” because it’s right there in the same line as the operation. No scrolling, no indentation labyrinth.

Also, there’s something a little more honest about it. You’re being explicit about what you’re okay ignoring. Nothing fancy. Just “if this error happens, we’re cool.”

When It Actually Makes Sense to Use suppress()

There are times when ignoring an error is part of the plan. For example, deleting a bunch of temp files at the end of a script. You don’t care if some of them aren’t there anymore—you just want the ones that are to go away without any fuss.

import os
from contextlib import suppress

temp_files = ["temp1.txt", "temp2.txt", "temp3.txt"]

for f in temp_files:
    with suppress(FileNotFoundError):
        os.remove(f)

That’s nice. No unnecessary branching, no if os.path.exists() dancing around before deleting. Just a loop that says: try it, ignore the noise if the file’s already gone.

But I’ll admit, there’s a line here. If I’m working on something critical—say, parsing data files that other systems depend on—I might want the noise. Sometimes silence is dangerous. Ignoring an exception without knowing the context can backfire if you’re not careful.

So the rule of thumb I’ve settled on: if I expect the error and have decided it’s not worth worrying about, I use suppress(). If there’s even a small chance the error might signal a bigger problem, I stick with the old-fashioned try-except, maybe throw in a log or warning.

It’s Not Just About Files

It surprised me how often this comes up outside of file handling. Take this example: you’re reading from a bunch of input files, but it’s okay if some of them aren’t there.

from contextlib import suppress

files = ["data1.csv", "data2.csv", "data3.csv"]

for file in files:
    with suppress(FileNotFoundError):
        with open(file, "r") as f:
            print(f"Processing {file}")
            # Add file processing logic here

No need to clutter your code with checks. If the file isn’t there, the script just moves on. That’s all you wanted anyway.

And technically, suppress() can catch any exception type. You can even pass in multiple ones like suppress(ValueError, TypeError)—though I don’t do that often. It feels like sweeping dust under the rug without even checking what kind of dust it is.

The Tradeoff Nobody Talks About

Okay, let’s be honest about something. Using suppress() does make debugging harder if you’re not careful. Especially when you’ve forgotten you used it and something important slips through quietly.

It’s a bit like setting your phone on Do Not Disturb—you’ll sleep better, but you might miss an emergency call.

So if you’re the kind of person who throws suppress() all over the place without thinking twice, you’re probably asking for trouble. But if you’re using it the way it’s intended—to explicitly ignore well-understood, low-risk exceptions—it’s fine. Better than fine, actually. It keeps the noise down and your code focused.

Also, worth mentioning: performance-wise, suppress() doesn’t really do anything special. It’s just sugar. Under the hood, it’s wrapping your code in a try-except and catching whatever exceptions you fed it. So don’t expect a speed boost. The gain is entirely in readability.

In Summary, Use It Like You Mean It

suppress() isn’t magic. It’s just a tidy way of saying, “this error doesn’t matter.” If you’re confident that’s true, then it’ll help keep your code clean and your focus intact.

But it’s not a blanket for bad habits. It won’t fix sloppy exception handling or prevent you from ignoring a problem that actually is a problem. Use it when you’d otherwise be writing boilerplate try-except blocks that only exist to pass over a predictable, harmless error.

Think of it like muting your phone during a movie. You don’t want interruptions—but only when you know nothing urgent is coming.

And that’s what makes contextlib.suppress() worth knowing. Quiet, polite, and helpful—so long as you know what you’re asking it to ignore.