尝试[Result]，IO[Result]，或者[Error，Result]，我最后应该使用哪一个

Question

我想知道我的方法的特征是什么，这样我就可以优雅地处理不同类型的失败。

这个问题在某种程度上是我对Scala中错误处理的许多问题的总结。您可以在此处找到一些问题：

• 在Scala中抛出异常，什么是“官方规则”
• 选项和理解
• 任一单操作

目前，我理解如下：

• 两者都可以用作可能失败的方法调用的结果包装。
• Try是一种右偏，其失败是非致命异常。
• IO（scalaz）有助于构建处理IO操作的纯方法。
• 所有这三种语言都易于理解。
• 由于flatMap方法不兼容，这三种方法不容易在一个统一的系统中混合使用。
• 在函数式语言中，除非异常是致命的，否则我们通常不会抛出异常。
• 我们应该为真正异常的情况抛出异常。我想这就是尝试的方法。
• 创建可丢弃文件会给JVM带来性能成本，并且不打算用于业务流控制

存储库层

现在请考虑我有一个< code >用户存储库。< code>UserRepository存储用户并定义一个< code>findById方法。可能会发生以下故障:

< li >致命故障(< code > out of memory error ) < Li > IO失败，因为数据库不可访问/不可读

此外，用户可能丢失，从而导致 Option[User] 结果

使用存储库的JDBC实现，可以抛出SQL的、非致命的异常（违反约束或其他），因此使用try是有意义的。

当我们处理 IO 操作时，如果我们想要纯函数，IO monad 也是有意义的。

因此结果类型可能是：

• 尝试[选项[用户]]
• IO[选项[用户]]
• 别的？

服务层

现在，让我们介绍一个业务层，UserService，它提供了一些方法updateUserName（id，newUserName）来使用存储库先前定义的findById。

可能发生以下故障：

• 所有存储库故障都传播到服务层
• 业务错误：无法更新不存在的用户的用户名
• 业务错误：新用户名太短

则结果类型可以是：

• 尝试[要么[业务错误，用户]]
• IO[要么[业务错误，用户]]
• 还有别的吗？

这里的BusinessError不是可抛出的，因为它不是异常的失败。

用于理解

我希望继续使用for-comprehensive来组合方法调用。

为了理解，我们不能简单地将不同的单子混合在一起，所以我想我应该为我的所有操作提供某种统一的返回类型，对吗？

我只是想知道，在你的现实世界中，Scala应用程序是如何成功的，以便在发生不同类型的故障时继续使用理解。

目前，对于理解对我来说工作得很好，使用服务和存储库都返回要么[Error， Result]，但所有不同类型的故障都融合在一起，处理这些故障变得有点棘手。

您是否定义了不同种类的monad之间的隐式转换，以便能够使用for-comedions？

您是否定义了自己的 monad 来处理故障？

顺便说一下，也许我很快就会使用异步IO驱动程序。所以我想我的返回类型可能会更复杂：IO[Future[要么[BusinessError， User]]]

任何建议都是受欢迎的，因为我真的不知道使用什么，而我的应用程序并不花哨:它只是一个API，我应该能够区分可以显示给客户端的业务错误和技术错误。我试图找到一个优雅而纯粹的解决方案。

Answer 1

更新2[2020-09]：自从该答案首次被编辑以来，scala生态系统发生了一些演变。cat-效3正在谈论拥有一个专用的错误通道[更新2021-03：它最终选择不这样做]，calaz 8停滞不前，一个新的库出现了：ZIO，一个核心具有双仿函数IO monad（一个依赖注入系统，超出了当前问题的范围）的库在scala中获得了关注。

由于它有专门的错误通道，刚打到v1.0.0，题目还比较新颖，所以我回答了问题(和这个有关):ZIO错误通道是什么，如何获得一个关于里面放什么的感觉？。

它还处理了更一般的问题（如：发现应用程序的故障模式并处理它们，让futur dev/adminsys/用户在行为上有代理权，即使是在出现错误的情况下），并简要总结了我的演讲：应用程序中的系统错误管理。希望它能有所帮助，并为这个（大而复杂的）话题提供更多的背景。

@pthariens-flame的回答很棒，你应该把它用在你手头的任务上。

我想带来一些该领域最近发展的背景知识，所以这只是一个一般性的信息回答。

错误管理基本上是我们的头号工作，dev。快乐的道路是快乐和无聊的，它不是用户会抱怨的地方。大多数（所有？）问题在于过程中隐含的效果（尤其是I/O）。

管理问题的一种方法是遵循通常所说的“纯FP approch”，在程序的纯/完全和不纯/非全部部分之间画一条大红线。这样做时，您可以利用这种可能性来干净利落地处理错误。

最近（18个月？），Scala在该领域进行了大量的研究和开发。实际上，我相信Scala是当今所有语言中在这个非常具体的问题上最令人兴奋和最具破坏性的地方（但当然，它可能只是对可用性/最新信息的大脑偏见）。

Scalaz8、Monix和cat效果是这一快速发展的三个主要贡献者。因此，与这三个项目相关的任何内容（会议演讲、博客文章等）都将帮助您了解正在发生的事情。

因此，为了让故事保持简短，Scalaz8将改变IO建模的方式，以更好地考虑错误管理。约翰·德戈斯（John DeGoes）领导了这项工作，他在这方面提供了一些很好的资源：

文章：

• 不再有变形金刚：Scalaz 8 http://degoes.net/articles/effects-without-transformers 中的高性能效果
• 双函子 IO：远离动态类型错误处理 http://degoes.net/articles/bifunctor-io

视频：

• Scalaz 8效果系统的设计-John A. De Goeshttps://www.youtube.com/watch?v=CIPGZzbPpeg

Monix和猫效应也有很多东西，但我相信这个主题的大部分资源都发生在相应项目中的拉取请求中。

亚历山德鲁·内德尔库在一次谈话中介绍了这些问题一些背景情况:

<李>两个莫尼克溪的故事https://www.youtube.com/watch?v=JFbYQGG2Nb4

亚当·沃斯基（Adam Warski）在这里进行了比较：

• Scalaz 8 IO vs Akka（类型化）演员vs Monix（第1部分）https://blog.softwaremill.com/scalaz-8-io-vs-akka-typed-actors-vs-monix-part-1-5672657169e1这是一个很好的例子

最后，Luka Jacobowitz为猫部分撰写了一篇出色的文章：“Rethinking MonadError”https://typelevel.org/blog/2018/04/13/rethinking-monaderror.html 它用另一盏灯覆盖了很多相同的领域。

[编辑]：正如同行所注意到的那样，该领域（r）进化的跨度并不止于scala-land的跨度。有一项工作要做很多工作，试图使效果编码（IO等）更高性能。该领域的最新步骤是尝试使用Kleisli Arrows代替monads，以最大限度地减少JVM上的GC流失。

看：

• TraneIO “Arrows”的第一个（AFAIK）Scala实现：https://github.com/traneio/arrows
• John DeGoes（再次）谈到了这个主题：https://www.slideshare.net/jdegoes/blazing-fast-pure-effects-without-monads-lambdaconf-2018 和相应的PR，其描述很有见地：https://github.com/scalaz/scalaz/pull/1857

希望有帮助！

更新[2018-07]：reddit上有一个关于这个主题的长而有趣的帖子：“有人可以向我解释IO的好处吗？”https://www.reddit.com/r/scala/comments/8ygjcq/can_someone_explain_to_me_the_benefits_of_io/

约翰·德戈斯的贡献：“Scala战争：FP-OOP vs FP”http://degoes.net/articles/fpoop-vs-fp

Answer 2

这就是 Scalaz 的 EitherT monad 变压器的用途。IO[Either[E， A]]堆栈等效于AoseT[IO， E， A]，除了前者必须按顺序作为多个monad处理，而后者自动成为单个monad，它将任一功能添加到基本monad IO。同样，您可以使用 AnyT[Future， E， A] 向异步操作添加非异常错误处理。

一般来说，单声道变换器可以满足在单个中混合多个单声道以进行理解和/或单声道操作的需要。

编辑：

我假设您使用的是 Scalaz 版本 7.0.0。

为了在< code>IO monad之上使用< code>EitherT monad转换器，首先需要导入Scalaz的相关部分:

import scalaz._, scalaz.effect._

您还需要定义您的错误类型:< code>RepositoryError、< code>BusinessError等。这照常工作。例如，您只需要确保可以将任何< code>RepositoryError转换为< code>BusinessError，然后进行模式匹配以恢复错误的确切类型。

那么您的方法的签名就变成了:

def findById(id: ID): EitherT[IO, RepositoryError, User]
def updateUserName(id: ID, newUserName: String): EitherT[IO, BusinessError, User]

在每个方法中，您可以将基于 EitherT 和 IO 的 monad 堆栈用作单个统一的 monad，并像往常一样用于理解。AnyT将负责在整个计算过程中对基本monad（在本例中为IO）进行线程化，同时还像Auly通常那样处理错误（除了默认情况下已经右偏置，因此您不必不断处理所有常见的.right垃圾）。当您想要执行 IO 操作时，您所要做的就是通过在 IO 上使用 liftIO 实例方法将其提升到组合的 monad 堆栈中。

顺便说一下，当以这种方式工作时，EitherT伴随对象中的函数可能非常有用。