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

Go中的“转义”

panic

s 1（我的意思是，可能由包含您的程序包的公共API的函数产生的那些）用于处理 程序员
所做的错误。因此，如果您的函数获得了一个指向对象的指针，并且不能

nil

（例如，表示该值丢失），则继续并取消引用该指针，以使运行时

panic

本身恰好是

nil

。如果函数期望整数必须在某个范围内，

panic

则该整数不在该范围内-
因为在 正确的 程序中，可能传递给函数的所有值 都是
在这个范围内，如果不这样做，那么程序员要么就没有遵循API，要么就没有对从外部获取的值进行消毒，这也不是您的错。

在另一方面，如故障问题打开一个文件或pefrorm你的函数应该执行一些其他动作 正确调用时 应该 不会
引起

panic

S和函数返回一个适当的错误信息。

请注意，建议

null

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

TL; DR

关于运行时问题的处理，

• panic

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

---

1

panic

s的另一合法用途是从深度递归处理/计算中返回的快速“冷路径”；在这种情况下，

panic

应由您的包捕获并处理，相应的公共API函数应返回错误。见这和此获取更多信息。