Introduction

In Python, except: and except Exception as e: do not mean the same thing. The bare form catches almost everything derived from BaseException, while except Exception as e: catches normal application errors and leaves process-level exceptions alone.

What except: Actually Catches

A bare except: is equivalent to catching BaseException. That includes ordinary exceptions such as ValueError, but it also includes exceptions that usually should not be swallowed, such as KeyboardInterrupt, SystemExit, and GeneratorExit.

1try:
2    value = int("abc")
3except:
4    print("something went wrong")

This works, but it is too broad for most code. If the user presses Ctrl+C, the same handler could catch that interruption and keep the program running when it should exit.

That is why bare except: is usually reserved for top-level cleanup code where you plan to re-raise immediately or shut the program down in a controlled way.

Why except Exception as e: Is Safer

Exception sits below BaseException in Python’s exception hierarchy. Catching Exception handles the usual runtime problems without intercepting shutdown signals and interrupts.

1try:
2    value = int("abc")
3except Exception as e:
4    print(f"failed to parse number: {e}")

This version is better for application logic because:

• it avoids catching KeyboardInterrupt and SystemExit
• it gives you the exception object as e
• it makes logging and debugging easier

If you need the message, type, or traceback, binding the exception object is the right pattern.

Prefer Specific Exceptions When You Know the Failure Mode

Even except Exception as e: can still be too broad. In business logic, it is often better to catch the exact exception you expect.

1try:
2    value = int(user_input)
3except ValueError:
4    print("please enter digits only")

Specific handlers communicate intent. They also avoid masking unrelated bugs. If the code inside the try block later raises AttributeError because of a programming mistake, a ValueError handler will not hide it.

You can still combine specific handling with a broader fallback when needed.

1try:
2    data = load_config()
3    timeout = int(data["timeout"])
4except FileNotFoundError:
5    print("config file is missing")
6except ValueError as e:
7    print(f"invalid timeout: {e}")
8except Exception as e:
9    print(f"unexpected error: {e}")
10    raise

This structure handles known errors locally and allows truly unexpected problems to surface.

When Bare except: Is Acceptable

There are a few narrow cases where bare except: can make sense. One is a final boundary where you must perform emergency cleanup no matter what happens.

1try:
2    run_service()
3except:
4    shutdown_safely()
5    raise

Even here, the important detail is raise. The handler is not hiding the exception. It is performing cleanup and then letting the original exception continue.

Another example is tiny scripts where you are explicitly implementing a “catch everything, print friendly output, exit” behavior. Even then, except Exception is often still the better default.

Logging and Re-raising Correctly

If you catch an exception because you want to add context, avoid replacing it carelessly. Re-raise the original exception unless you have a strong reason to wrap it.

1import logging
2
3logger = logging.getLogger(__name__)
4
5try:
6    save_record(record)
7except Exception as e:
8    logger.exception("failed to save record")
9    raise

logger.exception includes the traceback automatically when called inside an exception handler. That usually gives you more useful diagnostics than printing str(e) alone.

Common Pitfalls

The biggest pitfall is swallowing exceptions silently.

1try:
2    process()
3except Exception:
4    pass

This turns real failures into invisible corruption or missing output. If you catch an exception, either handle it meaningfully, log it, or re-raise it.

Another mistake is putting too much code inside a try block. A wide try block can catch unrelated exceptions and make debugging harder. Keep the risky operation as small as practical.

Developers also sometimes believe except Exception as e: catches everything. It does not. That is a feature, not a limitation. Letting interrupts and exit requests propagate is usually the correct behavior.

Summary

• 'except: catches BaseException, including interrupts and exit signals.'
• 'except Exception as e: catches normal application errors and gives access to the exception object.'
• In most code, prefer specific exception types over either broad form.
• Use bare except: only at very controlled boundaries, and usually re-raise.
• Never catch exceptions just to ignore them without logging or recovery.