当一个 try-catch 块与类似 Either 的 monad 结合时，可以解释为 monad 吗？答案

【问题标题】：Can a try-catch block be interpreted as a monad when coupled with a Either-like monad?当一个 try-catch 块与类似 Either 的 monad 结合时，可以解释为 monad 吗？
【发布时间】：2021-01-04 16:40:41
【问题描述】：

Functional Programming in C++ 在第 10.5.2 节中显示了 expected<T,E> monad，它与 Haskell 的 Either 相同。

到目前为止一切顺利。

然后，在第 10.5.3 节中，它声称显示 Try monad，或者至少这是该节的标题。

在这个“monad”中，只显示了一个函数，而不是mbind，它被称为mtry，它接受的输入不是值，它被包裹在“ try monad”，而是一个函数，它在运行时可以返回一个值或抛出一个异常，然后每个函数都被适当地包装在 expected monad 中。

所以如果我误解了作者的观点，除了我之外，大多数读者都清楚，或者这个标题真的具有误导性。

【问题讨论】：

Try 似乎只是通过将其包装在一个函数中来推迟效果（展开调用堆栈）。这就像你有一个可变数据类型并且只是推迟突变：这样的计算仍然可以运行它们时有害。

标签： c++ functional-programming try-catch monads

【解决方案1】：

您书中的mtry 函数基本上是构造expected monad 的有用方法，其中一方的类型始终是异常。

像 Scala 这样的其他语言有一个单独的 Try[A] 类型，其中所有 monady 的东西都是重复的，而不是构造一个 Either，但是有一些专门定制的方法很方便，因为你知道你正在处理一个异常，比如如果您在其map 中抛出异常，它将在Try 中重新捕获它，而不是传播它。这是包装命令式异常代码并将抛出的异常转换为值的好方法。

我想如果您了解 Scala 的 Try，那么本书的这一部分会更有意义。作者并不是真的试图向您展示如何制作一个完整的独立 Try，只是展示了该概念如何映射回前面的部分。他基本上省略了mbind，因为它与expected 没有任何不同。

【讨论】：