Error Propagation Patterns

Opening Scenario

Your service has a long call chain: HTTP handler → service layer → repository → database driver. A query fails. The HTTP handler returns a cheerful 200 OK with "status": "ok" and an empty list.

You grep for how the error travels:

• The database driver raised OperationalError.
• The repository wrapped the operation in try/except: pass "to avoid crashes."
• The service layer got None back, treated it as "no data," and returned [].
• The handler serialized [] as 200 OK.

Four layers of code made different assumptions about how to communicate failure. The error was silenced three times. The user sees success when the system failed.

There's no single "right way" to propagate errors — there are several patterns, and the bug is almost always that two layers disagree on which one they're using. What are those patterns, and how do you keep them consistent?

---

Question Progression

Q1: How does an error move from the place it happens to the place that handles it?

Question: A database driver can detect a dropped connection.…