Skip to main content

Errors and Boundaries Should Not Obscure Intent

What this concept is​

Robust code handles failure, but error handling should not bury the main idea of the code. Likewise, third-party libraries and boundary code should be isolated so the rest of the system does not absorb their noise and quirks.

Why it matters here​

Many codebases feel unreadable not because the business logic is hard, but because every important line is wrapped in defensive clutter, null checks, or third-party plumbing.

Concrete example​

Messy boundary:

def load_profile(client, user_id):
    result = client.fetch(user_id)
    if result is None:
        return None
    if "name" not in result:
        raise ValueError("bad payload")
    return result

Cleaner boundary:

def load_profile(profile_gateway, user_id):
    return profile_gateway.fetch_profile(user_id)

The messy handling can move into the gateway, so callers work with a cleaner contract.

Common confusion / misconception​

Clean error handling does not mean catching everything and returning a default. That often hides failure. The point is to separate the happy path from the recovery path and to make the contract explicit.

How to use it​

Prefer:

  • exceptions or explicit result objects over magic return codes
  • narrow, meaningful exception translation at boundaries
  • wrapper interfaces around unstable libraries
  • avoiding null as a vague all-purpose signal when a stronger contract is possible

Check yourself​

Why can a boundary wrapper make the rest of the codebase cleaner even if it adds one more layer?

Mini drill or application​

Choose one place where your code touches a file, database, network, or library API. Sketch a small wrapper that converts low-level failure details into a contract the rest of your code can understand.

Read this only if stuck​