Clojure技术问询：core.async中如何处理失败异步计算，{:right/:left}是否惯用？

Great question—handling failure states in core.async while maintaining that clean, chainable flow we get with some-> is a super common challenge, especially for heavyweight async operations where relying on nil as a failure sentinel just doesn't cut it (even though core.async channels can technically pass nil, I suspect you're looking for explicit, unambiguous failure handling here).

Is using {:right/:left} maps idiomatic Clojure? #

Absolutely. This is a lightweight take on the Either/Result pattern, which is widely adopted in the Clojure ecosystem. Instead of creating custom types (which adds overhead), using keyword-keyed maps like {:right successful-value} and {:left failure-reason} is idiomatic because:

• It leverages Clojure's core data structures (no external dependencies required)
• It's immediately readable to other Clojure developers
• You can easily extend it with additional context (e.g., {:left {:error-type :timeout :message "Operation timed out"}})

Many popular Clojure libraries (like cats for functional programming, or clojure.spec validation workflows) use this pattern, and you'll often see simplified variants like {:ok value} and {:error reason} which are equally idiomatic.

Implementing chainable async failure handling (like some-> for core.async) #

The goal here is to avoid nested if checks in go blocks and create a flat, chainable workflow. Here are two practical approaches:

1. A custom async-some-> macro #

You can build a macro that mimics some-> but operates on async Result values and handles channel parking:

(defmacro async-some->
  [initial-expr & async-fns]
  `(go
     (loop [current-result (<! ~initial-expr)]
       (if (or (not (:right current-result)) (empty? '~async-fns))
         current-result
         (recur (<! ((first '~async-fns) (:right current-result))))))))

Use it like this for a clean, chained flow:

;; Each heavy-op returns a channel that delivers {:right value} or {:left error}
(async-some->
  (heavy-async-operation-1)
  heavy-async-operation-2
  heavy-async-operation-3)

The macro will short-circuit at the first :left result and return it immediately, just like some-> stops at nil.

2. Pipeline-based processing with error passthrough #

If you're working with core.async pipelines (for batch processing), you can create a wrapper function that passes errors through unchanged while processing successful results:

(defn wrap-async-step [async-fn]
  (fn [result]
    (if (:right result)
      (async-fn (:right result))
      ;; Return the error as a ready channel to keep the pipeline flowing
      (go result))))

;; Example pipeline
(let [input-chan (chan)
      output-chan (chan)]
  (pipeline 4
            output-chan
            (map (wrap-async-step heavy-async-op3))
            (map (wrap-async-step heavy-async-op2))
            (map (wrap-async-step heavy-async-op1))
            input-chan)
  ;; Send jobs to input-chan, read results from output-chan
  )

This keeps errors moving through the pipeline so you can handle them all at the end (e.g., with a separate go block that listens for :left results).

Best Practices #

• Explicit > implicit: Always use clear Result maps instead of nil for failures. Nil is ambiguous in Clojure (it could mean "no value" or "failure"), so explicit :left/:error states make debugging and maintenance easier.
• Flatten nested go blocks: Use macros like async-some-> or loop/recur to avoid "callback hell" style nesting in your async code.
• Centralize error handling: Instead of handling errors at every step, pass them through to a dedicated error-handling channel or go block at the end of your workflow. This keeps your main logic clean.
• Leverage functional libraries (optional): If your team is comfortable with functional programming, libraries like cats provide a full Either type with built-in combinators (e.g., fmap, bind) that integrate seamlessly with core.async. This can reduce boilerplate even further.
• Add context to errors: Don't just return {:left :failure}—include details like error messages, timestamps, or input values to make debugging easier.

内容的提问来源于stack exchange，提问作者fevgenym