执行错误处理的现代方法…

我已经思考了一段时间了，发现自己不断发现警告和矛盾，因此我希望有人可以得出以下结论：

优先于错误代码的异常

据我所知，在从事该行业工作四年，阅读书籍和博客等之后，当前处理错误的最佳实践是抛出异常，而不是返回错误代码（不一定返回错误代码，而是返回错误代码）。类型代表错误）。

但是-对我来说这似乎是矛盾的...

编码接口，而不是实现

我们对接口或抽象进行编码以减少耦合。我们不知道或不想知道接口的特定类型和实现。那么，我们怎么可能知道应该寻找哪些异常呢？该实现可以抛出10个不同的异常，也可以不抛出任何异常。当我们确实捕获到异常时，我们正在对实现进行假设？

除非-接口具有...

异常规格

某些语言允许开发人员声明某些方法会引发某些异常（例如，Java使用throws关键字。）从调用代码的角度来看，这似乎很好-我们明确知道可能需要捕获哪些异常。

但是-这似乎表明...

泄漏抽象

为什么接口应该指定可以引发哪些异常？如果实现不需要引发异常或引发其他异常怎么办？在接口级别，无法知道实现可能要抛出的异常。

所以...

总结一下

当异常（在我看来）与软件最佳实践相矛盾时，为什么还要优先考虑它们？而且，如果错误代码非常糟糕（并且我不需要在错误代码的恶习上卖掉），还有其他选择吗？满足（如上所述）最佳实践要求但不依赖于调用代码检查错误代码返回值的错误处理技术的当前（或即将成为最新技术）是什么？

首先，我不同意这一说法：

优先于错误代码的异常

并非总是如此：例如，看一下Objective-C（使用Foundation框架）。尽管存在Java开发人员称为真正异常的东西，但NSError是处理错误的首选方式：@ try，@ catch，@ throw，NSException类等。

但是，许多接口确实会泄漏其抽象，并抛出异常。我相信这不是错误传播/处理的“异常”样式的错误。总的来说，我相信有关错误处理的最佳建议是：

在尽可能低的级别，周期内处理错误/异常

我认为如果坚持这一经验法则，抽象的“泄漏”量可能会非常有限并受到控制。

关于方法抛出的异常是否应该作为其声明的一部分，我认为它们应该：它们是此接口定义的协定的一部分：该方法执行A，或者对于B或C失败。

例如，如果一个类是XML解析器，则其设计的一部分应该表明所提供的XML文件完全是错误的。在Java中，通常通过声明预期遇到的异常并将其添加到throws方法的声明部分中来实现。另一方面，如果其中一种解析算法失败，则没有理由将该异常传递给未处理的对象。

归结为一件事： 良好的界面设计。 如果您对界面的设计足够好，那么就不会有任何异常困扰。否则，打扰您的不仅是例外。

另外，我认为Java的创建者出于安全方面的考虑，非常强烈地将方法声明/定义的异常包括在内。

最后一件事：某些语言，例如Eiffel，具有其他错误处理机制，并且根本不包含抛出功能。当不满足例程的后置条件时，将自动引发排序的“异常”。

我只想指出，异常和错误代码不是处理错误和备用代码路径的唯一方法。

您可以采用Haskell所采取的方法，在这种方法中，可以通过具有多个构造函数的抽象数据类型来发出错误信号（请考虑区别枚举或空指针，但类型安全，并且可以添加句法）糖或辅助函数，以使代码流看起来不错）。

func x = do
    a <- operationThatMightFail 10
    b <- operationThatMightFail 20
    c <- operationThatMightFail 30
    return (a + b + c)

operationThatMightfail是一个函数，返回包装在Maybe中的值。它的工作方式类似于可为空的指针，但是do表示法可确保如果a，b或c中的任何一个失败，则整个对象的计算结果为null。（并且编译器可以防止您意外产生NullPointerException）

另一种可能性是将错误处理程序对象作为附加参数传递给您调用的每个函数。该错误处理程序为每种可能的“异常”提供了一种方法，该方法可以通过传递给它的函数来发出信号，并且该函数可以使用该方法来处理发生异常的异常，而不必通过异常回退堆栈。

通用的LISP可以做到这一点，并通过语法支持（隐式参数）并使内置函数遵循此协议，从而使其可行。

是的，异常会导致抽象泄漏。但是错误代码在这方面是否还更糟？

解决此问题的一种方法是让接口准确指定在什么情况下可以抛出哪些异常，并声明实现必须将其内部异常模型映射到此规范，并在必要时捕获，转换和重新抛出异常。如果您想要一个“完美”的界面，那就是这样。

在实践中，通常足以指定逻辑上属于接口的异常，并且客户端可能希望捕获并对其进行处理。通常可以理解，当发生低级错误或出现错误时，可能还会有其他异常，并且客户端只能通过显示错误消息和/或关闭应用程序来进行一般处理。至少异常仍然可以包含有助于诊断问题的信息。

实际上，使用错误代码，几乎所有相同的事情最终都会发生，只是以更加隐式的方式发生，并且信息丢失的可能性大大增加，并且应用程序最终处于不一致状态。

在这里有很多好东西，我想补充一点，我们都应该警惕使用异常作为常规控制流程一部分的代码。有时人们陷入陷阱，凡是不是通常情况的事情都变成例外。我什至还看到过一个异常被用作循环终止条件。

异常表示“我在这里无法处理的事情发生了，需要去找其他人弄清楚该怎么做”。用户键入无效的输入也不例外（输入应通过再次询问等在本地进行处理）。

我见过的另一种退化的异常用法案例是，人们的第一反应是“抛出异常”。几乎总是在不编写catch的情况下完成此操作（经验法则：先编写catch，然后编写throw语句）。在大型应用程序中，当未捕获的异常从下层区域冒出来并使程序崩溃时，这将成为问题。

我不是反例外，但它们似乎像几年前的单例：使用得太频繁且不合适。它们非常适合预期的用途，但是这种情况并不像某些人想象的那样广泛。

泄漏抽象

为什么接口应该指定可以引发哪些异常？如果实现不需要引发异常或引发其他异常怎么办？在接口级别，无法知道实现可能要抛出的异常。

不。异常规范与返回和参数类型位于同一存储桶中，它们是接口的一部分。如果您不符合该规范，则不要实现该接口。如果您从不扔东西，那很好。在接口中指定异常没有任何泄漏。

错误代码非常糟糕。太可怕了 您必须手动记住每次检查并传播每个呼叫。首先，这违反了DRY，并且极大地破坏了您的错误处理代码。这种重复比任何异常都要大得多。您永远不能默默地忽略异常，但是人们可以并且确实默默地忽略返回码，这绝对是一件坏事。

那么异常处理可以有自己的接口实现。根据引发的异常类型，执行所需的步骤。

设计问题的解决方案是具有两个接口/抽象实现。一个用于功能，另一个用于异常处理。并根据捕获的异常类型，调用适当的异常类型类。

错误代码的实现是处理异常的一种常规方法。这就像字符串与字符串生成器的用法一样。

IM-ver-HO异常将根据具体情况进行判断，因为通过中断控制流，它们将增加代码的实际和可感知的复杂性，在许多情况下则不必要。抛弃与在函数内部引发异常有关的讨论-这实际上可能会改善您的控制流程，如果要研究通过调用边界引发异常，请考虑以下事项：

允许被呼叫者中断您的控制流可能不会提供任何实际好处，并且可能没有有意义的方式来处理异常。举一个直接的例子，如果正在实现Observable模式（使用C＃之类的语言，您到处都有事件，并且throws在定义中没有明确的提示），则没有实际的理由让Observer崩溃时破坏您的控制流，并且没有有意义的方式来处理他们的东西（当然，观察时一个好邻居不应该扔，但是没有人是完美的）。

上面的观察可以扩展到任何松散耦合的接口（如您所指出的）。我认为，在爬升3-6个堆栈帧之后，未捕获的异常很可能会出现在一段代码中，这实际上是一种规范：

• 太抽象了，以至于无法以任何有意义的方式处理该异常，即使该异常本身是向上转换的；
• 正在执行一般功能（根本不在乎失败的原因，例如消息泵或可观察的对象）；
• 是特定的，但职责不同，确实不应该担心；

考虑到上述情况，用throws语义修饰接口仅是微不足道的功能增益，因为通过接口协定的许多调用者只会在您失败时关心，而不是为什么。

我要说的是，这将成为滋味和便利性的问题：您的主要重点是在“异常”之后优雅地恢复呼叫者和被呼叫者的状态，因此，如果您有丰富的错误代码处理经验（即将从C的背景），或者如果您正在异常可能变成邪恶的环境（C ++）中工作，我不认为扔东西对于良好，干净的OOP是如此重要，以至于您不能依靠旧的模式，如果您不满意。特别是如果它导致SoC崩溃。

从理论上讲，我认为处理异常的SoC方式可以直接从以下观察中得出：大多数情况下，直接调用方只关心您失败了，而不是为什么。被调用者抛出，非常接近上方的某人（2-3帧）捕获了一个向上转换的版本，并且实际的异常始终沉入到专门的错误处理程序中（即使仅进行跟踪）-这是AOP派上用场的地方，因为这些处理程序可能是水平的。

优先于错误代码的异常

• 两者应该共存。

• 当您预期某些行为时，请返回错误代码。

• 当您没有预期到某些行为时，请返回异常。

• 当保留异常类型时，错误代码通常与一条消息相关联，但是一条消息可能会有所不同

• 异常具有堆栈跟踪，而错误代码则没有。我不使用错误代码来调试损坏的系统。

编码接口而不是实现

这可能是特定于JAVA的，但是当我声明接口时，我没有指定该接口的实现可能引发的异常，这只是没有意义。

当我们确实捕获到异常时，我们正在对实现进行假设？

这完全取决于您。您可以尝试捕获非常具体的异常类型，然后捕获更一般的异常Exception。为什么不让异常在堆栈中传播然后处理呢？或者，您可以查看方面编程，其中异常处理成为“可插入”方面。

如果实现不需要引发异常或引发其他异常怎么办？

我不明白为什么这对您来说是个问题。是的，您可能有一个永远不会失败或引发异常的实现，并且您可能有一个不断失败并引发异常的实现。如果是这种情况，请不要在接口上指定任何异常，这样就可以解决您的问题。

如果您的实现返回一个结果对象而不是异常，它将改变任何东西吗？该对象将包含您的操作结果以及任何错误/失败（如果有）。然后，您可以讯问该对象。

泄漏抽象

为什么接口应该指定可以引发哪些异常？如果实现不需要引发异常或引发其他异常怎么办？在接口级别，无法知道实现可能要抛出的异常。

以我的经验，接收错误的代码（通过异常，错误代码或其他任何方式）通常不会在意错误的确切原因-它将对任何失败做出相同的反应，但可能会报告错误。错误（错误对话框或某种日志）；并且此报告将与调用失败过程的代码正交进行。例如，此代码可以将错误传递给其他一些知道如何报告特定错误（例如，格式化消息字符串）的代码，并可能附加一些上下文信息。

当然，在某些情况下，它是需要特殊的语义附加到错误，并作出不同的反应在此基础上出现错误。这种情况应在接口规范中记录。但是，接口可能仍然保留引发其他异常的权利，而没有特殊含义。

我发现异常允许编写更加结构化和简洁的代码来报告和处理错误：使用错误代码需要在每次调用后检查返回值，并确定在出现意外结果时该怎么做。

另一方面，我同意例外揭示了实现细节，这些细节应隐藏在调用接口的代码中。由于不可能先验地知道哪段代码会引发哪些异常（除非它们像在Java中那样在方法签名中声明），因此通过使用异常，我们在代码的不同部分之间引入了非常复杂的隐式依赖关系，即反对最小化依赖的原则。

总结：

• 我认为异常允许使用更干净的代码，并且可以采用更具侵略性的方法进行测试和调试，因为未捕获的异常比错误代码（很快失败）更加明显并且更难以忽略。
• 另一方面，在测试过程中未发现的未捕获的异常错误会以崩溃的形式出现在生产环境中。在某些情况下，这种行为是不可接受的，在这种情况下，我认为使用错误代码是一种更可靠的方法。

右偏。

它不能忽略，必须加以处理，它是完全透明的。如果使用正确的左手错误类型，则它传达的所有信息都与Java异常相同。

缺点？具有适当错误处理的代码看起来令人作呕（所有机制均适用）。