language-agnostic - 异常机制的最佳实现是什么？

Question

大多数程序语言都有某种异常处理。一些语言有返回码，另一些有 try/catch 或rescue/retry 等，每种语言在大型团体开发工作中的可读性、健壮性和实际有效性方面都有自己的特点。哪一个是最好的，为什么？

Answer 1

我会说这取决于你的问题的性质。不同的问题域可能需要几乎任意的错误消息，而其他琐碎的任务只能在错误时返回 NULL 或 -1。

错误返回代码的问题在于您正在污染/掩盖错误，因为它可以被忽略（有时 API 客户端不知道他们应该检查错误代码）。它从手头的方法中提供（合理）有效的输出。

想象一下，您有一个 API，您在其中请求某个地图的索引键，将其存储在列表中，然后继续运行。API 稍后会发送一个回调，然后该方法可能会使用在本示例中可能为 -1 的键（错误代码）遍历表。BOOM，当您在某个数组中索引到 -1 时，应用程序会崩溃，而这些问题可能很难确定。这仍然是一个简单的例子，但它说明了错误代码的问题。

另一方面，错误代码比抛出异常更快，您可能希望将它们用于频繁访问的方法调用 - 如果返回这样的错误代码是合适的。我会说尝试将这些类型的错误代码封装在私有程序集中是完全可以的，因为您不会将这些错误代码暴露给 API 的客户端。永远记住要严格记录这些方法，因为这些应用程序的核弹可以在应用程序中逗留很长时间，因为它们在它关闭之前就被触发了。

就个人而言，我在某种程度上更喜欢两者的混合。我只是为此使用异常-异常-当程序运行到意外状态并且需要通知某些事情超出计划时。我不喜欢在我的代码中编写 try/catch 块，但这完全取决于个人喜好。

Answer 2

最适合什么？语言设计总是关于权衡。返回码的优点是除了常规的函数调用之外，它们不需要任何运行时支持；缺点是 1) 你总是必须检查它们 2) 返回类型必须有一个不是函数调用的有效结果的失败值。

自动异常处理的优点是代码中的错误条件不会消失。

各种语言（以及 Lisp 的条件系统、E 的弹出器等）中的异常处理语义之间的差异主要表现在程序应该继续执行时如何处理堆栈展开。

不过，总而言之：当您需要编写可读、健壮的软件时，自动异常处理非常有价值，尤其是在大型团队中。让计算机为您跟踪错误情况可以让您在阅读代码时少考虑一件事情，并且它消除了出错的机会。我唯一使用返回码来指示错误的情况是，如果我在没有异常处理的语言中实现一种语言。

Answer 3

try/catch/finally 出色地完成了这项工作。

它允许程序员优雅地处理特定条件以及一般故障。

总而言之，我确信每个都和其他任何一个一样好。

Answer 4

我必须使用 try/catch 的概念。我觉得就可读性而言，这为代码维护者提供了最多。只要异常输入正确并且相关的消息包含足够详细的数据（我个人不喜欢包括堆栈跟踪，但我知道很多人这样做，这将使这变得更简单）就应该相当直接地找到函数调用链更可追溯。）返回代码实现需要逐个程序的外部代码定义表。从个人经验来看，这既难以维护，又难以参考。

Answer 5

有关异常处理的不寻常观点，请参阅 Haskell 的Control.Exceptionmonad