Errors are part of the interface
Decide which failures to recover from, which to report, and which should stop the program.
BY THE END, YOU CAN
- Distinguish syntax errors from runtime exceptions
- Catch a specific failure at a useful boundary
- Preserve evidence while cleaning up resources
Diagram description: Read the file → It failed; It failed → Retry (known fix); It failed → Report, stop (otherwise); Retry → Clean up; Report, stop → Clean up
Read the failure
A syntax error prevents Python from understanding the program.
An exception occurs while an otherwise valid program executes: a conversion fails, a file is missing, or a dependency (another program or service you rely on) times out. The traceback shows the chain of calls and the point where the exception surfaced. Read the final exception type and message, then inspect the relevant caller and inputs.
Do not change code at random until the traceback disappears. First form an explanation that predicts why this particular input caused this particular failure.
Recover only when you have a policy
Catch an exception where you can make a meaningful decision.
A command-line input boundary can turn ValueError into a helpful message. A worker may reschedule a temporary network failure. A programming error should normally remain visible so it can be fixed.
Catching every Exception and continuing can turn a clear fault into silent data loss. Keep the protected block small enough that the handler cannot accidentally catch an unrelated failure. Report failed work explicitly instead of counting it as completed.
raw_attempts = "three"
try:
attempts = int(raw_attempts)
except ValueError:
print("Attempts must be a whole number")Cleanup is different from recovery
Resources such as files and locks need release whether the operation succeeds or fails.
A context manager, used with the with statement, is an object that sets something up and always cleans it up afterward, expressing that lifecycle. A finally block also runs during normal completion or exception unwinding, so it is appropriate for cleanup rather than pretending the operation succeeded. Preserve the original cause when translating exceptions into domain language.
In Relay, distinguish invalid job input from unavailable infrastructure: retrying invalid input usually repeats the same failure and wastes capacity that useful jobs need.
COMMON FAILURE MODE
Swallowing exceptions with an empty handler makes a broken system look healthy. Returning from finally can also suppress an exception.
TRY IT YOURSELF
Parse a user-supplied attempt count. Handle malformed text separately from a negative integer, and let an unrelated programming error remain visible.
Make the call in the laboratory.
The two-question checkpoint, your notes, and your saved progress are in the laboratory. Free, with no account.
Open in the laboratory ↗CONNECT IT TO RELAY
Give Relay separate completed, retryable, and invalid outcomes. Ensure one invalid job does not erase evidence about the rest of the batch.