Question 1

Why avoid bare except

Accepted Answer

A bare except catches everything derived from BaseException, which includes KeyboardInterrupt (Ctrl+C) and SystemExit. That means your program can't be killed cleanly with Ctrl+C and sys.exit() won't work. Even if you only want to silence errors, you should catch Exception at minimum so those system signals still propagate.

Question 2

Raising a ValueError

Accepted Answer

Python uses `raise` (not `throw`) and you pass an exception instance or class to it. Raising a plain string is a TypeError in Python 3 - only exception objects can be raised. `new` is not Python syntax, and calling ValueError(...) without raise just creates the object without raising it.

Question 3

finally always runs

Accepted Answer

When int("bad") raises ValueError, the except block runs and prints "caught". The finally block always executes regardless of whether an exception was raised or caught, so "done" prints immediately after. The order is except first, then finally.

Question 4

What finally does

Accepted Answer

finally is the cleanup guarantee. It runs whether the try block finished normally, raised an exception that was or was not caught, or even if a return or break statement was hit inside the try block. The canonical use is releasing resources: closing a file, releasing a lock, or rolling back a transaction. Context managers (with statements) automate this pattern, but finally remains important when you need cleanup logic that doesn't fit neatly into a context manager.

Question 5

Catching a parent exception type

Accepted Answer

Python raises KeyError specifically when a dict key is missing, not the generic LookupError. The except clause catches it because KeyError is a subclass of LookupError - but `type(e).__name__` reports the actual runtime type, not the type in the except clause. This matters when you need to distinguish which lookup failed; catching a parent type gives you broad coverage but you must inspect the type yourself.

Question 6

try/else behavior

Accepted Answer

The finally block runs before the function actually returns - Python executes finally even when the exit is via a return statement. Since "42" parses successfully, the else branch executes and returns "ok:42", but not before finally prints "fin". The outer print then shows the return value, giving "fin" then "ok:42".

Question 7

with statement on exception

Accepted Answer

When an exception is raised inside a with block, __exit__ is always called before the exception propagates. Because __exit__ returns False, the exception is not suppressed and continues to the outer try/except, which prints "caught". Returning True from __exit__ would suppress the exception entirely - a powerful but usually wrong choice.

Question 8

Re-raising exceptions

Accepted Answer

A bare `raise` re-raises the active exception with its original traceback intact, so the stack trace points to where the error first occurred. Writing `raise e` constructs a new raise point, so the traceback starts at your except block - making debugging harder because you lose the original call site. Always prefer bare `raise` when you just want to log and propagate.

Question 9

Exception vs BaseException

Accepted Answer

KeyboardInterrupt (Ctrl+C) and SystemExit both inherit from BaseException but not from Exception. That is intentional: catching Exception in a generic except clause does not accidentally swallow a user's attempt to quit your program. If you write except BaseException, you will also catch those signals and potentially trap the user in a loop they cannot exit. Use except Exception for broad error handling, and only catch KeyboardInterrupt or SystemExit explicitly when you have a specific reason to handle them.

Question 10

Exception chaining with raise from

Accepted Answer

The `raise X from Y` syntax sets the __cause__ attribute on X to Y, establishing an explicit exception chain. The outer handler catches RuntimeError, so type(err).__name__ is "RuntimeError". err.__cause__ is the original ValueError, so type(err.__cause__).__name__ is "ValueError". This chaining pattern is important when wrapping low-level library errors into domain-specific ones - you keep the root cause visible without exposing internal details in the exception type itself.

Question 11

contextlib.suppress

Accepted Answer

contextlib.suppress(exc_type) is essentially a context manager that calls __exit__ returning True for matched exceptions, absorbing them. The classic use case is `with suppress(FileNotFoundError): os.remove(path)` - you don't care if the file was already gone. It makes intent explicit: you're not forgetting to handle the error, you're deliberately ignoring it. Prefer it over a bare try/except/pass block because it names the expected exception and avoids an empty except body that looks like a bug.

Question 12

Custom exception with attributes

Accepted Answer

The custom exception stores amount=100 and balance=40 as instance attributes, so e.amount - e.balance is 60. Calling str(e) (or printing e directly) returns the message passed to super().__init__, which is "need 100, have 40". This pattern - storing structured data as attributes alongside a human-readable message - is exactly why you define custom exceptions: callers can programmatically inspect e.amount and e.balance rather than parsing a string.

Error Handling