使用错误进行功能参数验证是否是Go中的良好模式？

Question

使用错误返回码进行参数验证是否被视为良好做法？我的意思是有人应该在哪里使用错误而不是恐慌（有任何指导方针吗？）。

例如：

• 检查非nil +是否返回错误（如果为nil）是一个好习惯？
• 或检查正确的整数范围等。

我认为使用错误会使Go变得非常C-ish，并且看起来很糟糕。在这种情况下，恐慌是一个不错的选择吗？

还是Gopher应该使用Python / Ruby / JS方法“只是让它失败”？

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

并且即使我将返回错误代码：如果有人将错误的参数传递给函数但忽略了错误代码，该怎么办？->没事！所以说实话，我会说紧急情况对于这些情况很好，但是在使用错误代码代替紧急情况的语言中，这不是很清楚。

Answer 1

Go中的“转义” panics 1（我的意思是，可能由包含您的程序包的公共API的函数产生的那些）用于处理 程序员
所做的错误。因此，如果您的函数获得了一个指向对象的指针，并且不能nil（例如，表示该值丢失），则继续并取消引用该指针，以使运行时panic本身恰好是nil。如果函数期望整数必须在某个范围内，panic则该整数不在该范围内-
因为在 正确的 程序中，可能传递给函数的所有值 都是
在这个范围内，如果不这样做，那么程序员要么就没有遵循API，要么就没有对从外部获取的值进行消毒，这也不是您的错。

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

请注意，建议null在.NET和Java代码中显式检查公共API函数中的参数的建议具有使此类错误更易于阅读的不同目标。但是，由于99％的.NET和Java代码只允许所有异常传播到顶层（然后显示或记录），因此它只是将一个（由运行时生成的）异常替换为另一个。这可能使错误更加明显-
API函数执行失败，而不是调用堆栈中更深的位置-
但给这些API函数增加了不必要的麻烦。所以，是的，这是有根据的，但是我的主观意见是：在Go中让它崩溃只是可以的-您将获得描述性的堆栈跟踪。

TL; DR

关于运行时问题的处理，

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

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