validation - 使用错误的函数参数验证是 Go 中的一个很好的模式吗？

Question

使用错误返回码验证参数是否被认为是好的做法？我的意思是应该有人在哪里使用错误与 panic (有任何指导方针吗？)。

例如:

• 正在检查非 nil + 如果它是 nil 则返回一个错误 练习？
• 或检查正确的整数范围等

我想，使用经常会让 Go 感觉非常 C-ish 并且看起来很糟糕的错误。在这些情况下， panic 是一个很好的选择吗？

或者 Gopher 应该使用 Python/Ruby/JS 方法“让它失败”？

我有点困惑，因为在我的理解中， panic 是针对真正的“错误”。但是一直使用错误只是不好。

即使我会返回错误代码:如果有人将错误的参数传递给我的函数但忽略了错误代码，我该怎么办？ -> 什么都没有!所以老实说，我会说 panic 对于那些情况很好，但是在一种使用错误代码而不是 panic 的语言中，这并不是很清楚。

Answer 1

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

另一方面，诸如无法打开文件或执行您的函数应该执行的某些其他操作等问题在正确调用时应该不导致 panic s 并且函数应该返回适​​当的错误。

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

TL;DR

关于运行时问题的处理，

• panic用于编程错误；
• 返回错误是针对执行预期功能任务的问题。

---

¹ panics 的另一个合法用途是从深度递归处理/计算返回的快速“冷路径”；在这种情况下，panic 应该被你的包捕获和处理，并且相应的公共(public) API 函数应该返回错误。见 this和 this了解更多信息。