haskell - 何时使用 'ioError . userError' 而不是 'error'

Question

在阅读network package的源代码时，我注意到 ioError (userError ("Error description")) 的广泛使用来在 IO 操作期间引发错误。

由于这不是我第一次看到这种情况，我想知道使用此模式而不是 error 在实践中有什么区别？ Prelude 中的函数。

我知道 ioError 。 userError 引发 IOException在 IO monad 中，而 error 会引发 ErrorCall任何地方，但最终两者似乎注定要中止程序并显示简单的错误消息。

在哪些情况下 ioError 。 userError 比 error 更有优势？

Answer 1

传统上仅使用error来表示错误。错误是指开发人员期望永远不会发生的事情已经发生了。虽然 error 确实只是抛出一个 ErrorCall 异常，因此可以像任何其他异常一样捕获它，但通常从不捕获它，因此程序崩溃使用作为 error 参数提供的消息向最终用户通知错误。例如，稍后用户可以将该信息发布到问题跟踪器上。

另一方面，

IOException 旨在被捕获，并且只是标准 C/Java 控制流的改编。 userError 通常用于指定一些一般情况，当 the more specific types 都没有时。像 AlreadyExists 或 ResourceBusy 是合适的。

<小时/>

必须提到的是，这两个问题的解决方案都已经出现。

对于错误报告，存在基于 TemplateHaskell 的库，例如 loch-th和 placeholders ，它扩展了 error 以引用源代码中的特定位置和其他细节，例如“todo”虚拟变量，它让编译通过，但带有警告。

任何类型的异常通常都被认为是对原本简洁的 Haskell 类型系统的黑客攻击。最大的问题是您和编译器都没有关于是否进行某些计算的信息，例如IO ()，将引发任何类型的异常。事实证明，这很糟糕，出现了一些深深嵌套在依赖关系层次结构中的低级库引发的异常模式，然后触发了针对不同项目的一系列错误报告，并造成了大量的痛苦。这就是为什么最近正在开发基于异常的控制流的完全替代品，例如 EitherT monad transformer与相关errors util-library ，或 ErrorT transformer 。这两种解决方案都在类型系统中明确表示异常。但是 ErrorT has received some criticism支持EitherT+“错误”。