Hackage是否存在带显式错误类型的MonadThrow类？

类与实例定义 #

你定义的带显式错误类型的MonadThrow类及其实例如下：

class (Typeable e, Monad m) => MonadThrow e m where
  throw :: forall a. e -> m a

instance Typeable e => MonadThrow e (Either e) where
  throw = Left

instance (Typeable e, Monad m) => MonadThrow e (EitherT e m) where
  throw = hoistEither . throw

与现有库的对比 #

• 对比exceptions包的MonadThrow：你的实现不会将错误类型转换为字符串，避免了类型信息丢失。
• 对比mtl包的MonadError：不存在m → e的函数依赖，且无需强制实现catchError方法。

问题解答 #

1. Hackage是否已有类似实现 #

目前Hackage上没有完全匹配你这个定义的实现，但有一些相近的设计：

• monad-exception库提供了带显式错误类型的异常处理类，但它更偏向绑定Exception类型，而你的实现仅依赖Typeable，灵活性更高。
• 部分小众库尝试剥离MonadError的函数依赖，但大多会保留捕获相关方法，和你只保留throw的轻量设计不同。

2. 方案是否新颖 #

你的设计有一定新颖性：

• 聚焦于仅抛出错误的最小化接口，无需强制实现捕获逻辑，降低了类的实现成本。
• 去掉MonadError的函数依赖后，同一个Monad可支持多种错误类型的抛出，调用端能灵活选择保留强类型错误或统一为宽泛错误类型，代码组合更简洁。

3. 潜在未察觉的问题 #

• 类型推断成本增加：由于没有函数依赖，部分上下文模糊的场景中，GHC可能无法自动推断e的类型，需要手动添加类型注解。
• 生态兼容性问题：Haskell多数错误处理代码基于mtl的MonadError或exceptions的MonadThrow编写，你的自定义类需要额外适配器才能和现有代码无缝集成。
• 捕获机制缺失：若后续需要捕获错误，你可能需要额外定义配套类，或结合现有捕获机制，这会提升设计复杂度。

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