Exceptions and error handling

The loan that quietly shrank

• A renewal function returns $-1$ when a loan would pass its limit. One caller forgets to check and adds $-1$ to the loan, so a 20-day loan becomes 19 days.
• No error, no message: the failure spread silently. Exceptions exist so that a failure cannot be ignored.

Raise, catch, clean up

• Exceptions 异常 carry an error up to the code that can decide what to do. raise throws one; try/except catches it by type.
• finally runs on every path, whether the body succeeded or failed.

A small, precise hierarchy

• A custom hierarchy lets callers catch exactly what they can handle: a broad base and specific children. A handler for a parent also catches every child.

class LoanError(Exception): ...
class RenewalError(LoanError): ...
class LimitError(RenewalError): ...

Check first, raise loudly

• renew(Loan(20), 15) checks before changing anything and raises LimitError('20+15 exceeds 30').
• The loan still reads 20. Because a failed call changed nothing, no rollback is needed.

Unwinding the stack

• A raise leaves the current function and climbs frame by frame, from renew through issue up to main, running each finally on the way, until an except matches by type.
• If nothing matches, the program stops with a traceback: loud, not silent.

Cleanup that always happens

• On the failing path finally runs after the handler; on the success path it runs straight after the body.
• So cleanup that must happen, such as releasing a lock or closing a file, goes in finally or a with block, never after the last statement.

Status values or exceptions?

• Use a status value 状态值 (such as None for "not found") for expected outcomes the caller handles right away.
• Use an exception for a broken contract or a failure the immediate caller cannot fix.

Worked example: cleanup on the failing path

Three common slips

Recap