error-handling - 当您编写代码时，您是主动还是被动地处理错误？

Question

换句话说，您是花时间预测错误并编写代码来解决这些潜在问题，还是按照您认为合适的方式编写代码，然后逐个问题地解决任何错误？

我最近一直在思考这个问题，我是一个非常被动的人。我编写代码，试一试，返回纠正错误并重复，直到应用程序按预期工作。然而，我的一位朋友提出，他会花时间思考如何解释每一行并在错误发生之前修复它们。

我必须指出，re-active 是纯粹的 PRE-live。我肯定会确保我的应用程序在它上线之前可以正常工作。

Answer 1

应该始终保持平衡。

太多的错误检查速度很慢，并导致垃圾代码。没有足够的错误检查会使您的程序在边缘情况下崩溃，这在交付后不太好发现。

所以你决定了一些代码应该有多可靠，并相应地实施错误检查。一些测试实用程序可能不是很可靠 - 错误检查较少。旨在由第三方搜索服务在深层背景中使用的 COM 服务器应该是超级可靠的 - 更多的错误检查。

Answer 2

我认为单独提出这个问题有点奇怪，而且非常主观，但是显然有一堆技术可以让你做到每一个。我倾向于使用这两个：

• 测试驱动开发（这似乎是主动的）
• 强大的静态类型（反应性，但是紧凑的迭代开发周期的一部分，例如，它由我的 ML 编译器强制执行，我编译了很多）

偶尔我会转入程序形式验证的世界。这绝对是“反应性的”，但如果你想得更早一点，它往往会使验证更容易。

我还必须说，我很重视编程中的很多前期想法。避免错误的最简单方法是一开始就不写它们。有时这是不可避免的，但通常多花一点时间思考问题可以带来更好质量的解决方案，然后可以使用我上面谈到的各种自动化方法来处理其余的问题。

Answer 3

我通常在编码时问自己一堆假设，比如

• 用户点击按钮，如果他们没有选择日期怎么办？
• 用户在搜索框中输入内容，如果他们尝试在其中输入 html 怎么办？
• 我的标签文本取决于共享驱动器中的值，如果它没有映射怎么办？

等等。通过这样做，我发现当应用程序上线时，错误会减少很多，我可以专注于修复更模糊的错误，而不是纠正本应开始的条件。

Answer 4

在考虑错误处理时，我遵循一个简单的原则：垃圾进，垃圾出。如果您不希望任何垃圾（例如无效输入）弄乱您的软件，您必须在软件中找到它可以进入并处理它的所有点。当然，你的软件越复杂，就越难找到每个入口点，但我觉得你做的越多，你以后需要的反应就越少。

Answer 5

我提倡积极主动的方法。

• 我尝试以这种风格编写代码，从而产生可维护和可靠的代码
• 我使用防御性编程技术来防止由于注意力不集中和类似情况而导致代码中出现愚蠢的错误
• 我根据堡垒原理设计数据库模型，每次奇异操作后SQL代码检查结果
• 我想到了代码的那部分可能发生的潜在问题，我对此进行了解释。不是针对所有可能性，而是针对我现在能想到的主要可能性。

这通常会导致软件运行相当顺畅。有时它甚至让我感到惊讶，但这是预期的目标，所以我们到了。

Answer 6

恕我直言，“错误”一词（或其松散的同义词“错误”）本身意味着它是一种无法预见的程序行为。

我通常会尝试在设计时考虑所有可能的场景。当然，通常不可能考虑所有可能的情况。但是考虑并考虑尽可能多的情况通常比尽快让某些东西工作更好。这节省了大量调试和重新设计代码的时间和精力。在实际将任何代码输入我的编辑器之前，我经常会拿着笔和纸坐下来完成最小的编程任务。

正如我所说，这不会消除所有错误。对我来说，它在调试时间方面得到了很多倍的回报。另一个好处是它带来了更可靠和可维护的设计，更少的错误修复黑客和以后添加的特殊情况。但无论如何，在代码完成后，您将不得不进行大量调试。

当您想要的只是模型或快速原型时，这并不适用。此外，诸如截止日期之类的实际限制通常会使全面评估变得困难或不可能。

Answer 7

什么样的编程？不可能以任何一般的方式回答这个问题。（这就像问“你玩的时候戴头盔吗？”——嗯，玩什么？）

在工作中，我正在开发一个数据库支持的网站。要求很严格，如果我没有预料到用户会如何搞砸，我会在一天中的某个奇怪的时间接到电话来修复它。

在家里，我正在编写一个程序……我什至不知道它会做什么。我无法处理“错误”，因为我不知道在这种情况下“错误”是什么，因为我不知道正确的行为会是什么。程序的整个目的可以而且经常确实在几分钟到几小时的时间尺度上发生变化，所以即使这么早花几分钟时间思考错误也是完全浪费时间。（它甚至比浏览 SO 更糟糕，因为错误处理增加了代码行。）

我想唯一普遍的答案是“我做的事情在长期节省时间方面是有意义的”，这毕竟是使用机器为我们工作的全部原因。