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

#1 楼

首先，我不同意以下声明：


优先于错误代码的异常


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

但是它是真的许多接口都因抛出异常而泄漏了其抽象。我相信这不是错误传播/处理的“异常”样式的错误。总的来说，我认为有关错误处理的最佳建议是：

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

我认为如果有人遵守该规则根据经验，抽象的“泄漏”量可能非常有限并且可以控制。

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

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

这全都归结为一件事：
好的接口设计。 >如果您对接口的设计足够好，那么就不会有太多的异常困扰。
否则，不仅仅是异常会困扰您。

此外，我认为Java的创建者具有强烈的安全原因，包括方法声明/定义的异常。

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

#2 楼

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

您可以像这样使用一种方法由Haskell拍摄，其中错误可以通过具有多个构造函数的抽象数据类型来表示（认为有区别的枚举或null指针，但类型安全，并且可以添加语法糖或辅助函数以使代码流看起来不错）。 >

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

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

另一种可能性是将错误处理程序对象作为额外的参数传递给您调用的每个函数。该错误处理程序为每个可能的“异常”提供了一种方法，该方法可以通过传递给它的函数来发出信号，并且可以由该函数用于处理发生异常的异常，而不必通过异常回退堆栈。 br />
通用LISP可以做到这一点，并通过语法支持（隐式参数）和内置函数遵循此协议使其变得可行。

#3 楼

是的，异常可能导致抽象泄漏。但是，错误代码在这方面是否还更糟？通过在必要时捕获，转换和重新抛出异常来对此模型进行建模。如果您需要“完美”的接口，那是应该走的路。

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

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

#4 楼

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

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

我见过的另一种简陋的异常用法案例是，那些人的第一反应是是“引发例外”。这几乎总是在不编写catch的情况下完成的（经验法则：先编写catch，然后再抛出throw语句）。在大型应用程序中，当未捕获的异常从下层区域冒出来并炸毁程序时，这将成为问题。

我不是反异常，但它们看起来像几年前的单例：过于频繁和不当使用。它们非常适合预期的用途，但是这种情况并不像某些人想象的那么广泛。

#5 楼

抽象泄漏

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


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

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

#6 楼

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

解决设计问题的方法是有两个接口/抽象实现。一个用于功能，另一个用于异常处理。并根据捕获的Exception的类型，调用适当的异常类型类。错误代码的实现是处理异常的一种常规方法。这就像字符串与字符串生成器的用法一样。

#7 楼

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

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

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


太抽象而无法处理即使异常本身被向上传播，该异常也会以任何有意义的方式；
正在执行通用功能（不必在乎您为什么失败，例如消息泵或可观察的对象）；
是特定的，但职责不同，真的不要担心；

考虑到上述情况，用throws语义修饰接口只是一种边际功能收益，因为通过接口协定，许多调用者会只关心您是否失败，而不是为什么。

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

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

#8 楼

优先于错误代码的异常



两者应共存。
当您预期某些行为时，请返回错误代码。
如果您没有预期的行为，请返回异常。
在保留异常类型的情况下，错误代码通常与单个消息相关联，但是消息可能有所不同
在错误代码没有异常的情况下，异常具有堆栈跟踪。我不使用错误代码来调试损坏的系统。


编码接口而不是实现


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


当我们肯定捕获到异常时，有关
实现的假设？


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


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


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

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

#9 楼

抽象泄漏

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


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

当然，在某些情况下需要为错误附加特定的语义，并根据发生的错误做出不同的反应。这种情况应在接口规范中记录。但是，该接口可能仍然保留引发其他异常的权利，而没有特殊含义。

#10 楼

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

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

总结：



我认为异常可以使代码更简洁，并且可以更积极地测试和调试，因为未捕获的异常非常多另一方面，错误代码比错误代码更容易看到和忽略。
另一方面，在测试过程中未发现的未捕获的异常错误会以崩溃的形式出现在生产环境中。在某些情况下，这种行为是不可接受的，在这种情况下，我认为使用错误代码是一种更可靠的方法。

#11 楼

要么右偏。

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

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