【问题标题】:How to check the exact type of error in recover?如何检查恢复中错误的确切类型?
【发布时间】:2016-03-13 20:29:24
【问题描述】:

我在这里遵循这个例子:

https://www.socketloop.com/tutorials/golang-smarter-error-handling-with-strings-contains-function

 if !strings.Contains(err.Error(), "timed out") {
    fmt.Printf("resulting error not a timeout: %s", err)
 }

但是,如果我在我的代码中这样做,我会得到这个

err.Error undefined (type interface {} 是没有方法的接口)

我想知道我在这里做错了什么,以及我应该如何检查确切的错误(在我的情况下,我想从错误“切片边界超出范围”中恢复)

最好的,

【问题讨论】:

  • 那个教程太可怕了。恐慌不是处理错误的典型方式,也不是将它们打印到标准输出并退出。通过错误字符串识别错误是最不受欢迎的识别方法。

标签: go


【解决方案1】:

使用类型断言获取error https://play.golang.org/p/BryV7YfZHS

defer func(){
    err := recover().(error)
    fmt.Println(err.Error())
}()

a := make([]int, 0)
a[1] = 0

但我建议你不要这样做。首先,你不应该使用recover。在几乎所有情况下,这意味着你做错了什么。相反,修复恐慌的代码。

其次,不要使用字符串匹配来确定错误原因。它不好的原因有很多,但我只想说它不是 Go 的做事方式。我了解您可能正在使用 API,但您可能没有选择,而是尝试找到更好的方法。使用类型断言,类型切换来获取确切的错误类型并从那里开始。

【讨论】:

  • 谢谢。事实上,我使用的是别人的代码,因此有点不愿意修复不属于我的代码。无论如何,这次我采纳了你的建议并绕过了它,而不必使用讨厌的字符串匹配方法。很高兴知道有一些选项,但我会为您的答案添加书签。 :)
猜你喜欢
  • 2011-01-10
  • 1970-01-01
  • 2017-12-31
  • 1970-01-01
  • 2023-02-04
  • 2017-07-30
  • 1970-01-01
  • 2023-03-07
  • 1970-01-01
相关资源
最近更新 更多