示例 - 甚至是初学者示例 - 是否包含错误处理代码？

Question

在recent interview中，Brian Kernighan被问到了这个问题。我引用他的回复：

  布莱恩：我对此感到很伤心。错误处理代码往往体积庞大，非常无趣且没有破坏性，因此它常常妨碍学习和理解基本语言结构。同时，重要的是提醒程序员错误确实发生，并且他们的代码必须能够应对错误。

     

我个人的偏好是在教程的前面几部分中忽略错误处理，除了提到错误可能发生之外，类似于忽略参考手册中大多数示例中的错误，除非某些部分的内容是错误。但这可以强化无意识的信念，即忽视错误是安全的，这总是一个坏主意。

我经常在这里和我自己的博客上留下代码示例中的错误处理，我注意到这是Stack Overflow的一般趋势。我们是在加强坏习惯吗？我们是否应该花更多的时间来处理错误处理的例子，或者它是否只是为了说明这一点？

Answer 1

我认为这可能是一种改进，如果在发布示例代码时我们至少会发表评论，说你应该在某些地方放置错误处理代码。这可能至少有助于使用该代码的人记住他们需要进行错误处理。这将保留用于错误处理的额外代码，但仍将强化需要错误处理代码的想法。

Answer 2

任何提供的示例代码至少会被复制粘贴到生产代码中一次，因此在编写代码时应尽力而为。

Answer 3

除了在演示编码点时混乱代码的问题之外，我认为问题变成了， 你选择如何处理示例代码中的错误？

也就是说，你做什么？对于一个应用程序来说，致命的是另一个应用程序是非致命的。例如如果我无法从网络服务器（无论是404错误还是无响应的服务器）检索某些信息，如果没有这些数据就无法做任何事情，这可能是致命的。但如果这些数据是你正在做的事情的补充，那么也许你可以没有它。

因此，上述内容可能仅指示记录错误。这比完全忽略错误要好。但我认为通常困难在于知道如何/何时（以及何时没有）从错误中恢复。也许这本身就是一个全新的教程。

Answer 4

示例应该是说明性的。他们应该始终尽可能少地分散注意力。这是一个元例子：

假设我们想要从文件中读取一个数字，添加3，然后将其打印到控制台。我们需要展示一些东西。

infile = file("example.txt")
content = infile.read()
infile.close()
num = int(content)
print (3 + num)

罗嗦，但是正确，除了有一些可能出错的事情。首先，如果文件不存在怎么办？如果确实存在但不包含数字会怎么样？

因此，我们将展示如何处理错误。

try:
    infile = file("example.txt")
    content = infile.read()
    infile.close()
    num = int(content)
    print (3 + num)
except ValueError:
    print "Oops, the file didn't have a number."
except IOError:
    print "Oops, couldn't open the file for some reason."

在显示如何处理由此引发的错误的几次迭代之后，文件处理和解析。当然，我们想展示一种表达try子句的更多pythonic方式。现在我们放弃错误处理，因为这不是我们所展示的。

首先让我们消除不需要的额外变量。

infile = file("example.txt")
print (3 + int(infile.read()))
infile.close()

由于我们没有写它，也不是长期运行过程中的昂贵资源，所以保持开放实际上是安全的。它将在程序终止时关闭。

print ( 3 + int(file("example.txt").read()))

然而，有些人可能认为这是一个坏习惯，并且有一个更好的方法来处理这个问题。我们可以使用上下文来使它更清晰一些。当然，我们会解释一个文件将在一个with块的末尾自动关闭。

with file("example.txt") as infile:
    print (3 + int(infile.read()))

然后，既然我们已经表达了我们想要的一切，那么我们将在本节的最后展示一个完整的例子。另外，我们还会添加一些文档。

# Open a file "example.txt", read a number out of it, add 3 to it and print
# it to the console.
try:
    with file("example.txt") as infile:
        print (3 + int(infile.read()))
except ValueError: # in case int() can't understand what's in the file
    print "Oops, the file didn't have a number."
except IOError: # in case the file didn't exist.
    print "Oops, couldn't open the file for some reason."

这实际上是我通常看到指南所表达的方式，而且效果非常好。当任何部分缺失时，我通常会感到沮丧。

Answer 5

我不经常不同意BWK，但我认为初学者的例子特别是应该显示错误处理代码，因为这是初学者很难解决的问题。更有经验的程序员可以将错误处理视为已读。

Answer 6

我认为解决方案位于中间位置。如果要定义一个函数来查找列表'y'中的元素'x'，则可以执行以下操作：

function a(x,y) 
{
   assert(isvalid(x))
   assert(isvalid(y))
   logic()
}

没有必要明确说明输入有效的原因，只是读者应该知道逻辑假定有效输入。

Answer 7

错误处理本身就是一种范式;它通常不应包括在示例中，因为它严重破坏了作者试图遇到的重点。

如果作者希望传递有关特定域或语言中的错误处理的知识，那么我更愿意作为读者有一个不同的章节，其中概述了错误处理的所有主要范例以及这对其他章节的影响。

Answer 8

我有一个想法是在你的示例代码中包含如下所示的行：

DONT_FORGET_TO_ADD_ERROR_CHECKING();   // You have been warned!

所有这一切都是为了阻止代码为盲目复制和粘贴的人编写“蝙蝠”（因为显然DONT_FORGET_TO_ADD_ERROR_CHECKING()没有在任何地方定义）。但这也很麻烦，可能会被视为粗鲁。

Answer 9

我会说这取决于具体情况。在博客文章或教科书中，我将专注于执行或演示所需功能的代码。我可能会给出错误处理的强制性点头，或许，甚至可以检查但是用省略号来存储代码。在教学中，您可以通过包含太多不直接关注手头主题的代码来引入许多混淆。特别是在SO中，较短（但完整）的答案似乎是首选，因此在这种情况下处理“手的波浪”错误可能更合适。

也就是说，如果我提供了一个可供下载的代码示例，我通常会尽可能完整并包含合理的错误处理。这里的想法是，为了学习，这个人总是可以回到教程/博客并使用它来帮助理解实际实现的代码。

根据我的个人经验，这是我对如何呈现TDD的问题之一 - 通常您只会看到开发的测试，以检查代码是否在主要执行路径中成功。我想看到更多的TDD教程包括为备用（错误）路径开发测试。我认为，这方面的测试是最困难的，因为它需要你思考，而不是应该发生什么，而不是所有可能出错的事情。

Answer 10

我见过的一种方法，特别是在Advanced Programming in the UNIX Environment和UNIX Network Programming中的方法是用错误检查代码包装调用，然后在示例代码中使用包装器。例如：

ssiz_t Recv(...)
{
    ssize_t result;
    result = recv(...);
    /* error checking in full */
}

然后，在调用代码时：

Recv(...);

这样你就可以显示错误处理，同时允许调用代码流清晰简洁。

Answer 11

我不认为错误处理应该在示例中，如果它模糊了逻辑。但是一些错误处理只是做某些事情的习惯用法，而在这种情况下包括它。

另外，如果指出需要添加错误处理。对于 deity 的喜爱也指出了需要处理的错误。

这是阅读一些例子中最令人沮丧的部分。如果您不知道自己在做什么（我们必须假设示例的读者......），您不知道要查找哪些错误。这将“添加错误处理”建议转变为“此示例无用”。

Answer 12

不，除非示例的目的是演示异常处理的一个方面。这是我的一个宠儿 - 许多例子试图展示最佳实践并最终模糊和复杂的例子。我在代码示例中始终看到这一点，首先定义一组接口和继承链，这些示例不是必需的。过度复杂化的一个主要例子是我去年在TechEd做过的动手实验。该实验室在Linq上，但是我被编写的示例代码创建了一个多层应用程序。

示例应该从最简单的代码开始，这些代码演示了这一点，然后逐步进入实际使用和最佳实践。

顺便说一句，当我要求求职者的代码样本时，几乎所有人都小心翼翼地展示他们对异常处理的知识：

public void DoSomethingCool()
{
    try
    {
         // do something cool
    }
    catch (Exception ex)
    {
        throw ex;
    }
}

我已经收到了数百行代码，每个方法都是这样的。我已经开始为使用throw的人奖励积分;而不是扔ex;

Answer 13

示例代码不需要包含错误处理，但它应该演示正确的安全编码技术。许多网络代码段都违反了OWASP前十名。