Clojure core.async异步风格下错误传播问题的优化方案咨询

我在使用core.async以类似async/await的模式开发时，遇到了go块错误静默丢失的问题，以及go-try/<?组合在批量操作中错误无法向上传播的问题，以下是对应的分析和优化方案：

1. 基础问题：go块错误静默丢失 #

默认情况下，go块内抛出的异常会被静默吞噬，不会向上传播：

(defn go-uh-oh
  []
  (go
    (throw (Exception. "uh-oh"))))

(<!! (go
      (let [a-chan (go-uh-oh)
            b-chan (go-uh-oh)]
        [(<! a-chan) (<! b-chan)])))

这段代码的顶层<!!会直接返回[nil nil]，异常完全丢失，无法感知错误发生。

2. 常规解决方案：go-try与<?宏 #

通过封装go-try和<?宏可以解决单链路的错误传播问题：

• go-try：将go块包裹在try-catch中，捕获异常后将错误对象写入返回的通道
• <?：从通道取值时，若取出的是错误对象则立即重新抛出

修改后的代码能正常传播错误：

(defn go-uh-oh
  [arg]
  (go-try
   (throw (Exception. "uh-oh"))))

(<??
 (go-try (let [a-chan (go-uh-oh 1)
               b-chan (go-uh-oh 2)]
           [(<? a-chan) (<? b-chan)])))

此时异常会向上传播，顶层<??会抛出对应的错误。

3. 组合操作中的新问题 #

当使用a/merge、a/into这类批量组合操作时，go-try生成的错误对象会被当作普通值收集，无法自动向上传播：

(<?? (a/into [] (a/merge [(uh-oh-go-try) (uh-oh-go-try)])))

这段代码会返回包含两个Error对象的向量[Error, Error]，但不会抛出异常，错误再次“丢失”在集合中。

4. 优化方案 #

方案一：封装批量错误检查工具 #

编写一个工具函数，在收集完结果后自动检查集合中的错误，一旦发现错误就抛出：

(defn check-errors [coll]
  (if-let [err (some #(when (instance? Throwable %) %) coll)]
    (throw err)
    coll))

;; 使用方式
(<?? (go-try
       (let [results (<? (a/into [] (a/merge [(uh-oh-go-try) (uh-oh-go-try)])))]
         (check-errors results))))

这种方式保持了原有组合操作的语义，同时显式完成错误检查，适合需要保留所有结果或批量处理错误的场景。

方案二：自定义组合操作符 #

封装支持错误传播的批量操作宏/函数，在组合过程中一旦捕获到错误就立即终止并抛出：

(defmacro go-merge-and-check [chans]
  `(go-try
     (let [result-ch# (a/merge ~chans)]
       (loop [results# []]
         (if-let [val# (<? result-ch#)]
           (if (instance? Throwable val#)
             (throw val#)
             (recur (conj results# val#)))
           results#)))))

;; 使用方式
(<?? (go-merge-and-check [(uh-oh-go-try) (uh-oh-go-try)]))

这种方式会在第一个错误出现时立即终止流程并抛出异常，适合“快速失败”的场景，避免不必要的计算。

方案三：扩展<?的集合处理能力 #

修改<?宏，使其在遇到集合类型时自动递归检查错误：

(defmacro <?
  [ch]
  `(let [val# (a/<! ~ch)]
     (cond
       (instance? Throwable val#) (throw val#)
       (coll? val#) (mapv <? val#) ; 递归处理集合中的通道或已收集的结果
       :else val#)))

这种方式需要确保集合中的元素要么是通道要么是普通值/错误，适合统一错误处理逻辑、减少重复代码的场景，但可能会增加额外的递归开销。

总结 #

选择哪种方案取决于业务需求：

• 若需要保留所有结果并批量处理错误，选方案一
• 若需要快速失败，避免无效计算，选方案二
• 若希望统一错误处理逻辑，减少重复代码，选方案三

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