exception - 显式引发异常的应用

Question

在程序中显式引发异常有哪些应用和优势。例如，如果我们在这里专门考虑 Ada 语言，它提供了一个在程序中引发异常的接口(interface)。示例:

raise <Exception>;

但是我们需要明确提出异常的优势和应用领域是什么？

例如，在一个接受参数之一为字符串的过程中:

function Fixed_Str_To_Chr_Ptr (Source_String : String) return C.Strings.Chars_Ptr is
...
begin
...
  -- Check whether source string is of acceptable length
  if Source_String'Length <= 100 then
  ...
  else
    ...
    raise Constraint_Error;
  end if;

  return Ptr;

exception
     when Constraint_Error=>
        .. Do Something..
end Fixed_Str_To_Chr_Ptr;

如果我在上述函数中引发异常并在传递的字符串长度限制超过可容忍限制时处理它，是否有任何优势或良好做法？还是一个简单的 If-else 处理程序逻辑应该完成这项业务？

Answer 1

我会让我的 2 美分作为答案，以便捆绑各个方面。让我们从一般问题开始

But what are the advantages and application areas where we would need to raise exceptions explicitly?

引发异常的典型原因有几个。它们中的大多数都不是 Ada 特定的。

首先，可能存在使用或不使用异常的一般设计决策。一些一般标准:

• 即使实际上从未抛出异常，异常处理程序也可能会产生运行时间成本(参见例如 https://gcc.gnu.org/onlinedocs/gnat_ugn/Exception-Handling-Control.html)。这可能是 Not Acceptable 。
• 与其他语言的互操作性问题可能会排除使用异常，或者至少要求没有任何异常会离开在 Ada 中编程的部分。
• 在某种程度上，这个决定也是一个品味问题。来自一门毫无异常(exception)的语言的程序员可能会对仅依赖于检查返回值的设计更有信心。
• 有些程序比其他程序更能从异常(exception)中受益。如果传统的错误处理掩盖了实际的程序结构，那么可能是时候出现异常了。另一方面，如果潜在错误很少、易于检测并且可以在本地处理，则异常可能比传统处理错误更能掩盖潜在的执行路径。

一旦做出使用异常的一般决定，问题就会出现，何时何地不适合在您的代码中提出它们。我在评论中提到了一个一般标准。想到什么:

• 异常不应该是正常的、预期的程序流程的一部分(它们被称为 exceptions，而不是 expectations ;-))。这部分是因为控制流更难看到，部分是因为潜在的运行时间成本。
• 可以在本地处理的错误不需要异常。 (不过，为了获得统一的错误处理，引发一个仍然很有用。我将在下面看到您的代码片段时讨论这个问题。)
• 另一方面，如果函数不知道如何处理错误，则异常非常有用。对于可以从各种上下文(GUI、控制台程序、嵌入式、服务器...)调用的实用程序和库函数尤其如此。异常允许错误在调用链中向上传播，直到有人可以处理它，而中间层中没有任何错误处理代码。
• 有人说图书馆应该only expose custom exceptions,至少对于任何预期的错误。例如。当发生 I/O 异常时，将其包装在自定义异常中并显式 raise 该自定义异常。

现在是您的具体代码问题:

Is there any advantage or good practice if I raise an exception in the above function and handle it when the passed string length bound exceeds the tolerable limits? Or a simple If-else handler logic should do the business?

我不是特别喜欢这样(虽然我不觉得它很糟糕)，因为我上面的一般论点(“如果你可以在本地处理它，就不要引发”)表明简单的 if/else 更清晰.¹ 例如，如果函数很长，则异常处理程序将远离错误位置，因此人们可能想知道异常究竟发生在哪里(并找到一个 raise 位置并不能保证一个人已经找到了所有这些，所以审阅者必须仔细检查整个函数!)。

这取决于具体情况。如果错误可能在多个地方发生，那么引发异常可能会很优雅。例如，如果几个字符串太短，最好通过异常处理程序进行集中式错误处理，而不是将 if/then/elses(嵌套？？)分散在函数体中。这种情况很常见，a legitimate case can be made for using goto constructs语言无一异常(exception)。一个异常(exception)显然是优越的。

---

¹但实际上，您如何处理那里的错误？您有保证的日志记录设施吗？你回什么？调用者是否知道结果可能无效？也许你应该扔而不是抓。