如何将ErrIO操作提升至Shake的Action monad及相关疑问

很高兴能帮你解答这两个关于Shake的问题！

你自己写的runErr2action其实已经是非常合理的实现思路了！核心逻辑就是通过runErr把ErrIO计算转换为IO (Either String a)，再根据结果决定是抛出错误终止构建，还是返回正常结果。

我可以给你一个更简洁的版本，用either函数替代case表达式，让代码更紧凑：

import Control.Monad.IO.Class (liftIO)
import Control.Exception (throwIO)

runErr2action :: ErrIO a -> Action a
runErr2action op = liftIO $ runErr op >>= either throwIO return

这个版本和你的代码功能完全一致——liftIO负责把IO操作嵌入到Action monad中，either throwIO return则把Either结果映射为抛出异常或者返回值。Shake会自动捕获这些异常，并将其作为构建错误展示出来，完全符合构建系统的错误处理预期。

这个问题要从Shake的设计定位和错误处理哲学来理解：

• 构建场景的错误特性：Shake是为构建系统设计的，而构建过程中的绝大多数错误（比如文件缺失、编译失败、依赖不满足）都是不可恢复的。这种场景下，MonadError提供的“捕获-恢复”错误处理模式其实用处不大，反而会增加不必要的复杂度。Shake更倾向于让错误直接终止当前构建流程，清晰报告问题，而不是让开发者尝试恢复。
• Action的状态模型限制：Action内部维护着构建的依赖跟踪、进度状态等信息，这些状态是单向累积的，没有设计回滚机制。而MonadError的catchError要求在错误发生时能够恢复到之前的状态，这和Shake的状态模型不兼容——一旦某个步骤出错，之前记录的依赖信息已经生效，回滚没有实际意义。
• 作者的设计选择：Shake的开发者认为，对于构建系统来说，直接使用IO的异常机制已经足够满足需求，引入MonadError反而会让API变得臃肿。如果确实需要处理少数可恢复的错误，像你那样手动转换ErrIO到Action的方式，反而更灵活，也能更好地控制错误处理的逻辑。

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