在 Go 中使用错误进行函数参数验证是一种很好的模式吗？

Question

使用错误返回码进行参数验证是否被认为是好的做法？我的意思是有人应该在哪里使用错误与恐慌（是否有任何指导方针？）。例如：检查非零+如果它是零则返回错误是一个好习惯吗？或检查正确的整数范围等。我想，使用错误通常会让 Go 感觉非常 C-ish 并且看起来很糟糕。在这些情况下，恐慌是一个很好的选择吗？或者 Gopher 应该使用 Python/Ruby/JS 方法“让它失败”？我有点困惑，因为恐慌是我理解中真正的“错误”。但是一直使用错误是不好的。即使我会返回错误代码：如果有人将错误的参数传递给我的函数但忽略了错误代码，我该怎么办？-> 没什么！所以老实说，我会说恐慌对那些情况很好，但在错误代码用于恐慌的语言中，这不是很清楚。

Answer 1

Go 中的"Escaping" panics ¹（我的意思是，那些可能由构成包的公共 API 的函数产生的）是用来处理程序员所做的错误。因此，如果您的函数获得一个指向对象的指针，并且这不能nil（例如，指示该值丢失），则继续并取消引用该指针以使运行时panic本身（如果它恰好是nil. 如果一个函数需要一个必须在某个范围内的整数，panic如果它不在那个范围内——因为在一个正确的程序中，所有可能传递给你的函数的值都是 在那个范围内，如果他们不这样做，那么要么程序员没有遵守 API，要么他们没有清理从外部获取的值，这又不是你的错。

在另一方面，如故障问题打开一个文件或pefrorm你的函数应该执行一些其他动作正确调用时应该不会引起panicS和函数返回一个适当的错误信息。

请注意，null在 .NET 和 Java 代码中对公共 API 函数中的参数进行显式检查的建议具有不同的目标，即使此类错误更具可读性。但是由于 99% 的 .NET 和 Java 代码只是让所有异常传播到顶层（然后显示或可能被记录），因此它只是用另一个替换一个（由运行时生成的）异常。这可能会使错误更加明显——在 API 函数中执行失败，而不是在调用堆栈更深处的某个地方——但会为这些 API 函数增加不必要的麻烦。所以是的，这是自以为是，但我的主观意见是：在 Go 中让它崩溃是可以的——你会得到一个描述性的堆栈跟踪。

TL; 博士

关于运行时问题的处理，

• panics 用于编程错误；

• 返回错误是针对执行预期功能任务的问题。

---

¹panic s 的另一个合法用途是从深度递归处理/计算返回的快速“冷路径”；在这种情况下，panic应该由您的包捕获和处理，并且相应的公共 API 函数应该返回错误。有关更多信息，请参阅此和此。

Answer 2

这个答案是主观的。以下是我的想法：

关于恐慌，我喜欢 Go By Example ( ref ) 中的这句话

恐慌通常意味着出现意外错误。大多数情况下，我们使用它来在正常操作期间不应该发生的错误或我们不准备优雅处理的错误上快速失败。

在您的用例描述中，我认为您应该提出错误并处理错误。我还认为，当您正在使用的函数提供错误状态时，检查错误状态是一种很好的做法，并且用户应该检查文档中是否提供了错误状态。

如果我遇到从您正在编写的函数返回的错误，我会用来停止执行，我检查了它并且没有办法从中恢复。