Bare Exception Handling in Python

Bare `except:` handlers can catch even process-control exceptions, while `except Exception:` still catches a wide range of application failures. Prefer specific exception types and use broad handling only at a deliberate boundary with a clear recovery or reporting policy.

Bare exception handling means using `except:` without naming an exception type. It can catch nearly any exception, including `KeyboardInterrupt` and `SystemExit`, which are signals that a user or the runtime may be trying to stop the program.

`except Exception:` is also broad, but it does not catch exceptions such as `KeyboardInterrupt` and `SystemExit`, since those derive directly from `BaseException`. For ordinary application code, catching `Exception` is often less hazardous than a bare `except:`, but it can still hide unrelated bugs.

Prefer catching the specific exception types that the code can handle meaningfully. If an error cannot be handled locally, let it propagate or catch it at a boundary where the program can log context, return an appropriate response, or clean up resources.

A broad handler can be appropriate at a deliberate boundary, such as a worker loop that must log an unexpected job failure and continue processing later jobs. Keep that handler scoped, record the exception details, and avoid silently pretending the operation succeeded. Use `finally` or a context manager for cleanup that must happen regardless of whether an exception occurs.

Key points

• A bare `except:` catches more than ordinary application errors, including common shutdown signals.
• `except Exception:` is narrower than a bare handler, but can still hide bugs.
• Catch specific exception types when the code has a defined way to respond.
• If an error is not handled locally, let it propagate or handle it at an explicit boundary.
• Use `finally` or context managers for cleanup rather than swallowing exceptions.

Interview questions

What does a bare `except:` catch, and why can it be risky?

A bare `except:` catches exceptions derived from `BaseException`, including process-control exceptions such as `KeyboardInterrupt` and `SystemExit`. This can make it difficult to stop a program or reveal an important shutdown condition. It may also hide bugs by treating unrelated failures as though they were expected. Prefer a specific exception type, or use `except Exception` when a boundary genuinely needs to handle ordinary unexpected errors.

How does `except Exception` differ from a bare `except:`?

`except Exception` catches the usual family of application errors, while allowing exceptions such as `KeyboardInterrupt` and `SystemExit` to propagate. A bare `except:` also catches those process-control exceptions. Neither form is automatically safe: catching `Exception` can still mask programming errors if the code silently ignores them. Use the narrowest handler that supports a deliberate recovery action.

How would you handle an expected error without hiding unrelated failures?

Catch the specific error that the code knows how to handle, such as `FileNotFoundError` when a missing file has a defined fallback. Do not catch a broad type and then silently continue, because that can report success after a failed operation. If the error is not recoverable at this layer, allow it to propagate or translate it while preserving its cause. Add context where it helps the caller or operator understand the failure.

When is broad exception handling reasonable in a backend service?

Use a broad catch only at a boundary that has a clear policy for unexpected failures, such as isolating one job in a worker so later jobs can still run. The handler should capture diagnostic information and make the failure visible through logging, metrics, or an error result. It should not catch process-control exceptions accidentally; `except Exception` is usually more suitable than a bare handler for this purpose. Cleanup should generally be handled with `finally` or context managers rather than by swallowing errors.