Sentinel Error

预定义的特定错误，我们叫为 senitinel error， 这个名字来源于计算机编程中使用一个特定值来表示不可能进行进一步处理的做法。所以对于 Go，我们使用特定的值来表示错误。

• 不依赖检查 error.Error 的输出
• Sentinel errors 成为你 API 公共部分
• Sentinel errors 在两个包之间创建了依赖
• 结论：尽可能避免 sentinel errors

Error types

因为 MyError 是一个type，调用者可以使用断言转换成这个类型，来获取更多的上下文信息。

与错误值相比，错误类型的一大改进是它们能够包装底层错误以提供更多上下文。

一个不错的例子就是 os. PathError 它提供了底层执行了什么操作、那个路径出了什么问题。

调用者要使用类型断言和类型 switch，就要让自定义的 error 变 public。这种模型会导致和调用者产生强耦合，从而导致 API 变得脆弱。

结论是尽量避免使用 error types，虽然错误类型比 sentinel errors 更好，因为它们可以捕获关于出错的更多上下文，但是 error types 共享 error values 许多相同的问题。

因此，我的建议是避免错误类型，或者至少避免将它们作为公共 API 的一部分。

Opaque errors

在我看来，这是最灵活的错误处理策略，因为它要求代码和调用者之间的耦合最少。

我将这种风格称为不透明错误处理，因为虽然您知道发生了错误，但您没有能力看到错误的内部。作为调用者，关于操作的结果，您所知道的就是它起作用了，或者没有起作用（成功还是失败）。

这就是不透明错误处理的全部功能-只需返回错误而不假设其内容。

• Assert errors for behaviour, not type

在少数情况下，这种二分错误处理方法是不够的。例如，与进程外的世界进行交互（如网络活动），需要调用方调查错误的性质，以确定重试该操作是否合理。在这种情况下，我们可以断言错误实现了特定的行为，而不是断言错误是特定的类型或值。标准库中的应用：