一般函数问题（C++ / Java / C#）

Question

这个问题可能与语言无关，但我将重点关注指定的语言。

在处理一些遗留代码时，我经常看到这些函数的示例，这些函数（在我看来，显然）在它们内部做了太多的工作。我说的不是 5000 个 LoC 怪物，而是在它们内部实现先决条件检查的函数。

这是一个小例子：

void WorriedFunction(...) {
   // Of course, this is a bit exaggerated, but I guess this helps
   // to understand the idea.
   if (argument1 != null) return;
   if (argument2 + argument3 < 0) return;
   if (stateManager.currentlyDrawing()) return;

   // Actual function implementation starts here.

   // do_what_the_function_is_used_for
}

现在，当调用这种函数时，调用者不必担心要满足的所有先决条件，可以简单地说：

// Call the function.
WorriedFunction(...);

---

现在 - 如何应该处理以下问题吗？

就像，一般来说 - 这个函数应该只做它所要求的事情并将“先决条件检查”移至调用方：

if (argument1 != null && argument2 + argument3 < 0 && ...) {
   // Now all the checks inside can be removed.
   NotWorriedFunction();
}

或者- 它是否应该简单地针对每个先决条件不匹配抛出异常？

if (argument1 != null) throw NullArgumentException;

---

我不确定这个问题是否可以概括，但我仍然想在这里谈谈你对此的想法 - 可能有一些我可以重新思考的事情。 strong>

如果您有替代解决方案，请随时告诉我:)

谢谢。

Answer 1

每个函数/方法/代码块都应该有一个前提条件，它们是其设计工作的精确环境，以及后置条件，即函数返回时的状态。这些可以帮助您的程序员同事理解您的意图。

根据定义，如果前置条件为假，则代码预计不会工作，如果后置条件为假，则被视为有错误。

无论你把这些写在脑子里、写在设计文档的纸上、注释中，还是实际的代码检查中，这都是一个品味问题。

但从长远来看，如果将前置条件和后置条件编码为显式检查，那么生活会更容易。如果您编写此类检查，因为代码预计不会工作
如果前置条件错误，或者后置条件错误，则前置条件和后置条件检查应导致程序以易于发现故障点的方式报告错误。正如您的示例所示，代码不应该做的只是“返回”什么都不做，因为这意味着它已以某种方式正确执行。
（代码当然可以定义为不执行任何操作就退出，但如果是这种情况，前置条件和后置条件应该反映这一点。）

显然，您可以使用 if 语句编写此类检查（您的示例非常接近）：

if (!precondition) die("Precondition failure in WorriedFunction"); // die never comes back

但通常通过为称为断言的语言定义特殊函数/宏/语句来在代码中指示前置条件或后置条件的存在，并且当断言为假时，这种特殊的构造通常会导致程序中止和回溯。

代码的编写方式应如下所示：

void WorriedFunction(...)  
 {    assert(argument1 != null); // fail/abort if false [I think your example had the test backwards]
      assert(argument2 + argument3 >= 0);
      assert(!stateManager.currentlyDrawing());
      /* body of function goes here */ 
 }  

复杂的函数可能愿意告诉调用者某些条件已失败。这就是例外的真正目的。如果存在异常，从技术上讲，后置条件应该表示“在 xyz 条件下，函数可能会因异常而退出”。

Answer 2

这是一个有趣的问题。查看“Design By Contract”的概念，你可能会发现它很有帮助。

Answer 3

这取决于。

我想将我的答案分为情况 1、3 和情况 2。

情况 1、3

如果您可以安全地从参数问题中恢复，请不要抛出异常。一个很好的例子是 TryParse 方法 - 如果输入格式错误，它们只会返回 false。另一个例子（例外情况）是所有 LINQ 方法 - 如果 source 为 null 或强制 Func<> 之一，它们会抛出异常空。但是，如果它们接受自定义 IEqualityComparer 或 IComparer，它们不会抛出异常，而只需使用默认实现通过 EqualityComparer.Default 或 Comparer.Default。这完全取决于参数的使用上下文以及您是否可以安全地从中恢复。

情况 2

如果代码位于类似基础设施的环境中，我只会使用这种方式。最近，我开始重新实现 LINQ 堆栈，并且您必须实现几个接口 - 这些实现永远不会在我自己的类和方法之外使用，因此您可以在它们内部做出假设 - 外部将始终通过接口访问它们，并且无法自己创建它们。

如果您对 API 方法做出这样的假设，您的代码将在错误输入时抛出各种异常，并且用户不知道发生了什么，因为他不知道您的方法的内部。

Answer 4

“或者 - 它应该简单地针对每个先决条件不匹配抛出异常吗？”

是的。

Answer 5

您应该在调用和运行之前进行检查，如果您拥有该函数，则应该让它在传递的参数与预期不符时抛出异常。

在您的调用代码中应该处理这些异常。当然，传递的参数应该在调用之前进行验证。