Python Error Handling

Also Known As

TL;DR

Explanation

Python exceptions are objects in a hierarchy (BaseException > Exception > specific types). Best practices: catch the most specific exception possible, not bare except or except Exception. The else clause runs when no exception was raised — useful for code that should only run on success. finally always runs — use it for cleanup. Custom exceptions should inherit from Exception, not BaseException. Use raise from to preserve exception chains.

Common Misconception

Why It Matters

Common Mistakes

• Bare except: clause — catches everything including SystemExit and KeyboardInterrupt; always specify the exception type.
• Using pass in an except block — silently swallows the error with no logging or handling.
• Not using raise from to preserve the original exception context: raise NewException(...) from original_exc.
• Catching broad Exception when a specific type is known — makes error messages less informative and hides unrelated bugs.

Code Examples

# Silent exception swallowing — hides all errors:
def get_user(user_id):
    try:
        return db.fetch(user_id)
    except:  # Catches EVERYTHING including KeyboardInterrupt
        pass  # Returns None silently — caller has no idea what went wrong

# Specific exception handling with context:
class UserNotFoundError(ValueError):
    def __init__(self, user_id):
        super().__init__(f'User {user_id} not found')
        self.user_id = user_id

def get_user(user_id: int) -> User:
    try:
        return db.fetch(user_id)
    except DatabaseConnectionError as e:
        raise RuntimeError('Database unavailable') from e  # Preserve chain
    except RecordNotFoundError:
        raise UserNotFoundError(user_id)  # Domain-specific exception
    # No finally needed here — let other exceptions propagate

References

• ↗ https://docs.python.org/3/tutorial/errors.html

Tags

Related Terms