UpdatedAug 4, 2026

Python Exception Handling

Question Variations

"When should `else` be used with `try` and `except`?"
"Why is `except Exception` usually safer than a bare `except`?"
"How do you wrap a low-level exception without losing its cause?"
"What belongs in a `finally` block?"

Why This Is Asked

Exception handling exposes how you balance resilience with observability. Interviewers look for targeted error handling, useful error context, and cleanup that does not accidentally hide the original failure.

Key Concepts

Catch the narrowest exception type that can be handled meaningfully.
else runs only when the try suite succeeds; finally runs on every exit path.
raise ... from error preserves causal context when translating exceptions.
Exceptions should not be used as routine control flow when a clear ordinary branch exists.

Question Variations

“When should else be used with try and except?”
“Why is except Exception usually safer than a bare except?”
“How do you wrap a low-level exception without losing its cause?”
“What belongs in a finally block?”

Answers by Technology

+ Add Variant

PythonImprove this answer ✏️

Expected Answer (Python 3.14)

Handle only exceptions you expect and can recover from. Keep the try block small so that an except clause does not accidentally catch unrelated programming errors. Use else for work that depends on success, and use finally for cleanup that must run whether the operation succeeds or fails.

When translating a low-level failure into a domain-specific one, chain the original exception with raise ... from ... so logs and debuggers retain the cause.

class ConfigurationError(Exception):
    pass

def load_port(value):
    try:
        return int(value)
    except ValueError as error:
        raise ConfigurationError("PORT must be an integer") from error

try:
    port = load_port("not-a-number")
except ConfigurationError as error:
    print(error)

Why It Matters

Broad exception handling can turn real defects into silent bad results, while unhandled operational errors can make a service unreliable. Chaining and targeted handling make failures diagnosable without exposing implementation details to callers.

Common Mistakes

Using a bare except: clause: It also catches control-flow exceptions such as KeyboardInterrupt and SystemExit.
Catching Exception and continuing silently: This hides bugs unless the failure is logged or returned in a meaningful way.
Raising a replacement exception without from: The original cause is lost from the traceback.

Follow-up Questions

When does finally run? (Answer: When the try statement exits, whether by success, exception, or return.)
Why place as little code as possible in try? (Answer: It limits the operations that an except might mistakenly handle.)