exception - D中的惯用错误处理

Question

我试图找到有关处理错误的标准且公认的惯用D方式的资源，但找不到任何东西。如果您正在阅读error handling的官方文档，则可以在其中找到以下非常重要的声明:

• Errors are not part of the normal flow of a program. Errors are exceptional, unusual, and unexpected.
• Because errors are unusual, execution of error handling code is not performance critical.
• The normal flow of program logic is performance critical.

我之所以称其为重要，是因为将异常(exception)情况用于此类特殊情况的原因是导致本文得出结论的原因，即错误毕竟是特殊情况，而无论花费多少成本，异常(exception)都是解决之道。再次来自同一篇文章:

Because errors are unusual, execution of error handling code is not performance critical. Exception handling stack unwinding is a relatively slow process.

在某些特殊情况下，可能无法显式处理异常，但是异常的存在仍会影响事物的状态，因此应使用 exception safe scope guards。

我的主要问题是，上述解决方案及其文档中的示例确实是异常(exception)情况，当我们遇到与内存相关的问题时，这非常有用，但是我们不希望程序失败，我们想要维护完整性并在可能的情况下从这些情况中恢复，但是其他情况又如何呢？

众所周知，错误不仅用于特殊情况和意外情况，而且是在 call 者和被 call 者之间进行通信的方式。例如，可以在消毒器中使用错误。假设我们要为关联数组实现模式验证。单独的类型系统无法定义键和值的约束，因此我们创建了一个在运行时检查此类对象的函数。那么，如果架构失败了该怎么办？由于我们对它如何失败很感兴趣，因此其中发生的错误(即找到的无效数据)也应包含有关错误原因的信息，因此调用方将知道如何对此进行操作。根据第一篇文章的作者，使用异常是一种昂贵的抽象。根据同一篇文章的同一作者，使用C样式函数约定将返回值都用于错误状态是错误的方式。

那么，处理D中不是异常的错误的正确且惯用的方法是什么？

Answer 1

嗯，TLDR版本是使用异常是处理D中错误情况的惯用方式，但是当然，细节要比这复杂得多。

问题的一部分是什么构成错误。错误一词用于很多事情，因此，谈论错误可能会造成很大的困惑。某些类型的错误是程序性错误(因此是程序中错误的结果)，其他类型不是程序性错误，但灾难性很大，程序无法继续运行，而其他类型则依赖于诸如用户输入之类的东西，并且通常可以恢复从。

对于程序错误和灾难性错误，D具有Error类，该类派生自Throwable。 Error的两个常用子类是AssertError和RangeError-AssertError是断言失败的结果，而RangeError是您尝试使用越界索引对数组进行索引时得到的结果。这两个都是程序错误；它们是程序中错误的结果，从它们中恢复是没有意义的，因为根据定义，您的程序当时处于无效状态。一个不是bug的错误示例，但通常足以导致程序终止的灾难性后果是MemoryError，当new无法分配内存时抛出该错误。

抛出Error时，无法保证将运行任何清理代码(例如，析构函数和scope语句可能会被跳过，因为假设是因为您的代码处于无效状态，清理代码实际上可能使情况变得更糟)。该程序只是简单地展开堆栈，打印出Error的消息和堆栈跟踪，然后终止程序。因此，尝试捕获Error并使程序继续运行几乎总是一个可怕的主意，因为该程序处于未知且无效的状态。如果某事物被认为是Error，则它是一种错误条件被认为是不可恢复的条件，程序不应该尝试从中恢复。

在大多数情况下，您可能不会对Error进行任何明确的操作。当不使用-release进行编译时，将在代码中放入断言以捕获错误，但是您可能不会明确抛出任何Error。它们主要是D的运行时或正在运行的代码中的断言捕获程序中的错误的结果。

从Throwable派生的另一个类是Exception。它用于问题不是您的程序中的错误，而是由于用户输入或环境而导致的问题的情况(例如，用户提供的XML无效，或者您的程序尝试打开的文件不存在)。异常为函数提供了一种报告其输入无效或由于无法控制的问题而无法完成其任务的方式。然后，该程序可以选择捕获该Exception并尝试从中恢复，也可以让它冒泡到顶部并杀死该程序(尽管通常情况下，捕获它们并打印出更用户友好的内容更加人性化而不是带有堆栈跟踪的消息)。与Error不同，Exception确实导致运行所有清理代码。因此，捕获它们并继续执行是完全安全的。

但是，程序对异常的响应以及是否可以做更多的工作，而不是向用户报告错误发生并终止，这取决于异常发生的原因和程序在做什么(这是某些代码子类为何的一部分)。 Exception-它提供了一种报告错误的方法，而不仅仅是错误消息，并且允许程序根据发生错误的事件的类型以编程方式对其做出响应，而不是简单地响应“某事”发生错误的事实)。通过使用异常来报告出现问题的时间，它可以使代码不直接处理错误，除非它是您要在代码中处理错误的位置，从而使代码总体上更加简洁，但不利的是有时您可以获取异常被抛出，这是您不期望的，如果您对何时会抛出的东西不够熟悉。但这也意味着报告的错误不会像错误代码那样被遗漏。如果您忘记处理异常，则在异常发生时就会知道它，而对于类似错误代码的代码，很容易忘记检查它或没有意识到自己需要这样做，并且错误可能会丢失。因此，尽管意外的异常可能很烦人，但它们有助于确保您在程序中发现问题时就可以发现它们。

现在，使用断言和异常的最佳时间可能有点技巧。例如，在按契约(Contract)设计时，您可以使用断言来检查函数的输入，因为任何使用无效参数调用该函数的代码都违反了契约(Contract)，因此被认为是错误的，而在防御性编程中，您无需假设该输入有效，因此该函数始终检查其输入(不只是在不使用-release进行编译时)，并且在失败时会抛出Exception。哪种方法更有意义取决于您在做什么以及该功能的输入可能来自何处。但是，使用断言来检查用户输入或程序控制范围之外的任何内容都是不适当的，因为输入错误并不是程序中的错误。

但是，虽然通常来说，处理D中错误情况的惯用方式可能是抛出异常，但有时确实没有意义。例如，如果错误情况实际上极有可能发生，则抛出异常是处理它的代价非常高的方法。通常，异常情况对于并非一直发生的情况足够快，但是对于经常发生的情况(尤其是对性能至关重要的代码)，异常情况可能会太昂贵。在这种情况下，执行类似错误代码之类的方法可能更有意义-或者在该函数无法获得结果时执行诸如返回Nullable并将其为null的事情。

通常，在合理的情况下假设函数将成功执行和/或在简化代码以使其成功执行时，使异常不必担心错误情况时，异常才是最有意义的。

例如，假设编写一个使用错误代码而不是异常的XML解析器。其实现中的每个函数都必须检查它调用的任何函数是否成功，然后返回自身是否成功，这不仅容易出错，而且这意味着在整个解析器中到处都有错误处理代码。另一方面，如果使用异常，则大多数解析器不必关心XML中的错误。除了遇到无效XML的代码而不必返回调用该函数所必须处理的错误代码之外，它还可以引发异常，并且调用链中的任何代码实际上都是处理错误的好地方(可能是代码那么首先调用解析器的代码是唯一必须处理该错误的代码。这样，程序中唯一的错误处理代码就是需要处理错误的代码，而不是大多数程序。这样的代码更干净。

异常真正清除代码的另一个示例是类似于std.file.isDir的函数。它返回给定的文件名是否与目录相对应，并在出现问题时(例如，文件不存在或用户无权访问)抛出FileException。为了使用错误代码，您将不得不做类似的事情

int isDir(string filename, ref bool result);

这意味着您不能简单地将其置于类似

if(file.isDir)
{
    ...
}

你会被丑陋的东西困住

bool result;
immutable error = file.isDir(result);
if(error != 0)
{
    ...
}
else if(result)
{
    ...
}

的确，在很多情况下，文件不存在的风险很高，这可能是使用错误代码的一个参数，但是 std.file.exists使得可以在调用 isDir之前轻松检查该条件，从而确保 isDir失败很少见情况-或如果所讨论的代码以很可能存在该文件的方式编写(例如，它是从 dirEntries获取的)，那么您不必费心检查该文件是否存在。无论哪种方式，其结果都比处理错误代码更整洁且更不易出错。

无论如何，最合适的解决方案取决于您的代码在做什么，并且在某些情况下，异常确实没有意义，但总的来说，它们是处理不是程序中的错误或错误的惯用方式。诸如内存不足之类的灾难性错误和 Error通常是处理程序中遇到的错误或灾难性错误的最佳方法。归根结底，要知道何时以及如何使用异常与其他技术相比是有点技巧的，并且通常需要经验来使人对它有良好的感觉，这就是为什么有关何时使用异常，断言和错误的问题的一部分。代码不时 pop 。