Poor Error Handling Practices

Poor error handling in Clojure rarely means “using exceptions at all.” It usually means losing the information, timing, or boundary clarity that makes failures diagnosable. The code catches too much, swallows too much, logs the same failure three times, or throws generic exceptions with no useful context.

A good error-handling design answers a few practical questions:

• what failed
• where it failed
• what context mattered
• whether the caller can recover
• who is responsible for logging or user-facing translation

When those answers are muddy, the code becomes much harder to operate.

Anti-Pattern: Swallowing Exceptions

This is the easiest error-handling mistake to write and one of the hardest to diagnose later.

1(try
2  (do-something-risky)
3  (catch Exception _
4    nil))

Now the system has lost:

• the stack trace
• the failure type
• the operational context
• the distinction between “missing value” and “real failure”

Sometimes returning nil is legitimate, but it should represent an actual domain absence, not a hidden exception.

The anti-pattern is turning a concrete failure into silent ambiguity.

Anti-Pattern: Catching Exception Too Early

Catching broad exceptions at low levels often hides the real semantics of failure.

Weak:

1(defn load-config [path]
2  (try
3    (slurp path)
4    (catch Exception e
5      (throw (Exception. "config failed")))))

This strips away useful details and replaces them with a message that is both generic and harder to debug.

If you wrap an exception, preserve context:

1(defn load-config [path]
2  (try
3    (slurp path)
4    (catch java.io.IOException e
5      (throw (ex-info "Failed to load config"
6                      {:path path
7                       :type :config/io-failure}
8                      e)))))

Now the caller gets:

• a domain-meaningful label
• structured context
• the original cause

The anti-pattern is catching broadly without improving the failure model.

Anti-Pattern: Logging and Rethrowing at Every Layer

Duplicate logging is a common operational problem.

Example:

• low-level HTTP client logs the exception
• service layer logs the exception again
• top-level request handler logs it a third time

This creates noisy logs without adding real information.

A better rule is usually:

• add context as failures cross boundaries
• log once at the operational boundary that owns reporting

The anti-pattern is confusing “adding context” with “logging again.”

Anti-Pattern: Throwing Exceptions with No Structured Data

Plain exception messages are often not enough in a data-oriented language like Clojure.

Weak:

1(throw (Exception. "Invalid order"))

Stronger:

1(throw
2  (ex-info "Order failed validation"
3           {:type :order/invalid
4            :order-id (:id order)
5            :missing-fields missing-fields}))

Structured data matters because callers and logs can inspect it without brittle message parsing.

The anti-pattern is flattening a rich failure into an unstructured string too early.

Anti-Pattern: Using Exceptions for Expected Domain Branches

Not every negative path is exceptional.

Expected cases often deserve ordinary data:

• search miss
• unauthorized but normal business refusal
• optional integration result absent
• validation failure that the user should correct

Sometimes a result map, tagged value, or explicit domain status is more honest than throwing.

The anti-pattern is using exceptions for control flow when the outcome is a normal business branch rather than an operational failure.

Anti-Pattern: Throwing Without a Boundary Strategy

Error handling becomes messy when every layer invents its own policy.

Questions to answer explicitly:

• which layer translates infrastructure failures into domain terms?
• which layer logs?
• which layer returns user-facing messages or HTTP status?
• which failures should stay as data rather than exceptions?

If those boundaries are unclear, code ends up with:

• low-level logging noise
• high-level generic failures
• inconsistent use of ex-info
• repeated try/catch wrappers with little value

Anti-Pattern: Losing the Cause Chain

Wrapping an error without preserving the original cause is another expensive mistake.

If you throw a new exception and discard the old one, diagnosis gets much harder. In Clojure, ex-info with a cause keeps the chain intact and is usually the better default for enriched exception context.

The anti-pattern is replacing a useful failure lineage with a prettier but less informative top-level message.

A Better Error Boundary Model

    flowchart TD
	    A["Low-level failure"] --> B["Add structured context at boundary"]
	    B --> C{"Recoverable domain case?"}
	    C -->|Yes| D["Return explicit data result"]
	    C -->|No| E["Propagate exception with cause"]
	    E --> F["Log once at operational boundary"]
	    F --> G["Translate for user or caller"]

This model keeps context, avoids duplicate noise, and makes recovery decisions explicit.

What to Do Instead

• use ex-info when adding domain-specific failure context
• preserve the cause when wrapping exceptions
• return ordinary data for expected business outcomes
• catch specific exception classes when you truly know how to handle them
• log at the boundary that owns operational reporting, not everywhere

Common Mistakes

• swallowing exceptions into nil or falsey ambiguity
• catching Exception without improving the failure model
• logging and rethrowing at multiple layers
• throwing plain string-only exceptions for rich domain failures
• using exceptions for expected, nonexceptional control flow

Key Takeaways

• Good error handling preserves meaning, context, and ownership.
• Not every failure path should be an exception.
• Structured error data is often more useful than free-form strings alone.
• Wrapping errors is only valuable when context is added and the cause is preserved.
• The cleanest systems decide clearly where logging, translation, and propagation happen.

Ready to Test Your Knowledge?