haskell - 与管道(-core)一起使用什么错误处理方法？

Question

我目前正在为我的一个小项目编写一些管道核心/attoparsec 管道。我希望每个解析器提供一个管道，等待解析器的 ByteString 输入并生成任何解析值(重新启动解析器)。如果没有错误处理，它将具有类似的类型

parserP :: Monad m => Parser a -> Pipe ByteString a m r

现在，我不确定如何处理解析错误。我目前的想法是:

• 将错误添加到返回类型(即在 Either ParseError r 中返回一个值，而不仅仅是 r)
• 要求 monad 提供错误处理机制(即要求 monad 接管管道来实现 MonadError)
• 通过将 Pipe 置于 ErrorT e m a 上，强制 monad 为任何 monad m
提供错误机制
• 添加参数，让用户指定行为(类似于(ParseError -> P.Pipe ByteString a m r)，并在发生解析错误时简单地绑定(bind)到由此提供的管道)<

第一个解决方案似乎是错误的，因为使用管道的返回类型进行错误处理似乎更像是一种黑客行为。一方面，它使管道的组合变得更加丑陋，并且似乎或多或少地被最终解决方案所包含(除了可能失去让下游管道能够通过使用 tryAwait 并停止等待值来从错误中恢复的能力) ？)。

第二个解决方案似乎是错误的，尽管我不太清楚为什么。可能因为它还需要一个参数将 ParseError 转换为 monad 具有的任何错误类型(除非我们希望要求 monad 实现 MonadError ParseError ，这似乎会导致大量的簿记)。最后，我似乎不记得在那么多地方看到过 MonadError，这表明使用它时存在一些问题。

第三种解决方案适用于我的情况，因为管道将成为具有用户指定的 monad(IO) 的管道的一部分，该 monad(IO) 不应该关心解析错误(它将网络数据解析为生成的格式)到用户指定的类型)。但它看起来并不那么优雅，而且一旦在任何其他上下文中使用，就会再次(可能？)导致大量的簿记工作。

我还没有真正考虑过最终的解决方案，但看起来有些复杂。

我将不胜感激对这个特殊情况的任何想法(如果我偏离并遗漏了一些明显的东西，我一点也不会感到惊讶)，以及对错误处理讨论的任何(或多或少相关)引用在管道(-core)/管道/interatee等中

编辑:另一种可能性可能是只采取一个单子(monad) Action (而不是一个完整的管道)，尽管我不太确定它是否可以概括、专门化，甚至等同于第四个 Action 。

Answer 1

如果可以的话，我想我可以通过这样描述这个选择来帮助组织大家对此的想法。您可以:

1. EitherT/ErrorT 内的层Pipe:

   EitherT e(管道 a b m)r

2. EitherT/ErrorT 之外的层 Pipe:

   管道 a b (EitherT e m) r

您想要前一种方法，它还有一个很好的属性，您可以将其设为 MonadError 的实例(如果您喜欢的话)。

为了了解两种方法之间的差异，第二种方法会在整个管道级别引发错误。第一个允许在单个管道的粒度上进行错误处理，并正确处理组合管道。

现在来看一些代码。如果您不介意的话，我会使用 EitherT，因为我更喜欢它:

import Control.Error
import Control.Pipe

type PipeE e a b m r = EitherT e (Pipe a b m) r

runPipeE = runPipe . runEitherT

p1 <?< p2 = EitherT (runEitherT p1 <+< runEitherT p2)

然后只需在 PipeE 中使用 catchT 和 throwT 就可以了。

这种方法还有另一个优点，即您可以有选择地将其应用于管道的某些部分，但是您需要在将其与其他管道组合之前负责处理潜在的异常值。您可以利用这种灵 active ，为管道的不同阶段使用不同类型的异常值，或者对于不会失败的阶段根本不使用它，并避免错误检查这些阶段的开销。