如何捕获错误并实现可追踪性？

**如何捕获错误并实现可追踪性** 在实现使用 TCP 的服务器时，`readNext()` 函数可能因连接丢失或解析错误而失败。对于捕获和追踪这些错误，有三个选项： * **不换行并返回哨兵错误：**该方法简单，但无法提供错误原因信息。 * **使用自定义错误类型进行换行并进行类型比较：**该方法提供错误原因信息，但需要编写额外的代码。 * **使用自定义错误类型进行包装并针对接口进行断言：**该方法提供错误原因信息和行为清晰度，但需要编写更复杂的代码。

我正在实现一个使用 tcp 的服务器。读取函数具有以下签名

func readnext() (message, error) 

该函数可能因两个原因而失败：

1. 连接丢失
2. 解析错误

我的第一反应是用 fmt.errorf() 包装错误。但是，我想为该包的使用者提供根据失败原因进行检查和分派的能力，因此据我所知，使用内置包装并不能提供该选项。

我读过“不要只是检查错误，要优雅地处理错误”，发现基本上他提倡使用自定义错误类型进行包装并在自定义接口上使用类型断言。我发现这非常冗长并且需要很多额外的代码。另外，我认为与我的错误类型相关的行为不会使其更清晰：

type ParseError interface {
  IsParseError() bool
}

type NetworkError interface {
  IsNetworkError() bool
}

我基本上看到三个选项：

• 不换行并返回哨兵错误
• 使用自定义错误类型进行换行并进行类型比较
• dave cheney 风格：用自定义错误类型包装并针对描述行为的接口进行断言。

我发现没有特别好的或优雅的解决方案。有什么建议吗？

解决方案

错误很复杂，因为错误很很复杂。

戴夫·切尼的博文包含以下声明：

我完全同意。考虑一些简单的事情，比如“从文件中读取数据”。这可能会失败。但是为什么会失败，您可以对这些失败采取什么措施吗？

以下是它可能失败的一些原因。这并不是所有可能原因的完整列表，只是其中的一些原因：

1. 该文件可能不存在。应该如此，但事实并非如此。

   您可能对此无能为力。

2. 也许该文件确实存在，但您无权访问它。你应该这样做，但你就是不这样做。

   对此您可能无能为力，除非您拥有管理员访问权限，在这种情况下，您可以授予自己权限并继续。

3. 也许该文件存在并且您有权访问它，但数据已损坏。

   您可能对此无能为力，但如果系统具有自我修复功能（存在此类系统），这可能是暂时的。

4. 文件可能暂时无法访问，因为它位于网络上并且网络已分区。

   这与情况 3 类似：等待并重试可能会解决问题（事实上，它可能比情况 3 更有可能解决）。

确实如此。它还需要首先产生错误的人进行合作，以便您可以做出这些细微的区分。那是因为您正在处理真正的硬件和软件系统，它们非常复杂。

这不是很令人满意，但这是事实。幸运的是，对于很多软件来说，很多错误情况都可以归结为“不是我的问题”：可以将无法打开和读取上面的某些文件（不存在或权限被拒绝）的前两个示例放入这个组。如果您正在编写文件列表实用程序或类似的东西，这可能没问题。如果您正在编写运行起搏器的代码，则因错误消息（“致命：无法报告心率”）而停止可能是，呃，致命的。您需要考虑上下文。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。