Golang Go语言中看到好多人吐槽错误处理，但我用的很爽啊
Golang Go语言中看到好多人吐槽错误处理，但我用的很爽啊
golang 的错误处理，我之前也吐槽，但从 1.13 开始吧就挺好用了。 之前吐槽点：
- 如果底层函数出错，只在上层打印错误信息，会丢失调用栈，不知道最开始的错误发生在哪里。
- 如果通过字符串追加的方式，加入调用栈信息，那么错误类型会丢失，无法像 if err == io.EOF 这样判断是什么错误。
现在已经不是问题了。
// LineInfo 返回调用此函数的代码所在函数、文件、行号
// 此函数应该在一个单独的文件中，比如，utils/getlineinfo.go
func LineInfo() string {
function := "xxx"
pc, file, line, ok := runtime.Caller(1)
if !ok {
file = "???"
line = 0
}
function = runtime.FuncForPC(pc).Name()
return fmt.Sprintf(" -> %s():%s:%d", function, file, line)
}
var ErrAuth = errors.New(“auth error”)
var ErrAccount = fmt.Errorf("%w: account not exist", ErrAuth)
var ErrPassword = fmt.Errorf("%w: incorrect password", ErrAuth)
func login(acc, pwd string) (string, error) {
if acc != “libai” {
return “”, ErrAccount
}
if pwd != “123456” {
return “”, ErrPassword
}
return fmt.Sprintf("key:AC34cvG-%d", time.Now().Unix()), nil
}
func getInfo(acc, pwd string) (string, error) {
key, err := login(acc, pwd)
if err != nil { // login 的错误
return “”, fmt.Errorf("%w%s", err, LineInfo())
}
// 打开下面的注释就会是 key 过期
//time.Sleep(time.Second)
msg, err := getIntro(key)
if err != nil { // key 错误
return "", fmt.Errorf("%w%s", err, LineInfo())
}
return msg, nil
}
var ErrKey = errors.New(“invalid key”)
func getIntro(key string) (string, error) {
if key != fmt.Sprintf(“key:AC34cvG-%d”, time.Now().Unix()) {
return “”, ErrKey
}
return "李白，号青莲居士", nil
}
func main() {
info, err := getInfo(“libai”, “123456”)
if err != nil && errors.Is(err, ErrAuth) { // 无论账号错误还是密码错误，都是认证错误
fmt.Printf("[info]%s\n", err.Error())
} else if err != nil {
fmt.Printf("[error]:%s\n", err.Error())
}
fmt.Println(info)
}
更多关于Golang Go语言中看到好多人吐槽错误处理，但我用的很爽啊的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
不可否认，if err != nil 导致代码的可读性变差，异常处理的逻辑和业务逻辑代码混杂在一起
更多关于Golang Go语言中看到好多人吐槽错误处理，但我用的很爽啊的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
你说的两个点，第三方的 errors 包都已经足够好用，现在的版本，go 自带的 error.Is()， 判断错误类型也够用了。
我觉得现在最大的痛点应该是要写一堆‘ if err!= nil {}’ ，代码块里可能有很多重复的错误处理逻辑还不好抽离封装， 为了少写这些重复逻辑，社区许多人推荐用 defer，现在我偶尔用 goto 。
写惯 c/c++的表示错误码很正常，普通错误，比如文件找不着这种，不算异常，就返回一个 errorcode 上层继续处理，程序可以继续正常运行
碰到各种异常，直接崩溃了就得了
我觉得可读性和可维护性更重要，有时候一个功能会用到另一个功能的部分函数，我可能会通过复制代码的方式，使两个功能减少联系。功能划分的合理，可能一个函数里只有一两个 if err != nil{}的地方，一点不影响阅读和美感，每个错误处理逻辑非常清晰，反而更优雅。而且不是所有的错误都要处理，信任边界的问题。总之，这是因人而异的，不是普适的，受人生观价值观的哲学范畴。
写分布式或者一致性要求高的场景，Golang 的这种错误处理是很爽的。
每一步，都要考虑怎么处理，如果用异常，才是真正的反人类。
当然，写一般的业务代码，自然是异常爽，直接抛出去，在顶层捕获处理就可以了。
同样写的很爽，觉得虽然 if err != nil 确实有些繁琐，但是也还好。
最近写 lua，因为太容易出 bug 了，现在用 https://github.com/teal-language/tl/ 加一些自定义的类型，基本上和写 go 没啥区别了。
其实大多数情况下错误处理都是向外抛<br>err := case1()<br>if err!=nil{<br> return nil,err<br>}<br><br>err := case2()<br>if err!=nil{<br> return nil,err<br>}<br><br>doSome()<br>
用 try catch 的话只用：<br>try{<br> case1()<br> case2()<br> doSome()<br>}catch(e){<br> throw e<br>}<br>
这不是高下立判吗？
这东西就属于 taste 的问题，而 taste 的问题往往是因为见的少，大多数情况下，我不相信一个写习惯 Haskell （还有其他抽象程度足够高的语言）的人，会对 Go 的错误处理感到满意。
但是异常引入了其它问题
1. 构造析构函数里能不能抛，怎么处理
2. checked exception vs unchecked exception
3. finally 中修改了返回值，会不会生效
4. 性能问题，异常比返回值慢的多
5. 忘记处理异常，或者处理不当
那我问一个问题，一个函数里需要字符串转整型的功能，如果字符串不是整数字符串，就当作 0 来处理怎么实现。现实中我有许多类似的需求，golang 实现如下：<br>func foo(index string) {<br> i, _ := strconv.Atoi(index)<br> // 忽略错误，继续处理，比如数据库某个字段默认是 0<br>}<br><br>
用抛出异常的方式怎么实现？
go 的 taste 比较另类点而已, 或者作者觉得直白够 simple 也是一种 good taste.
另外, 撇开 taste, 整体来说 go 用来做事情我个人还是比较满意的.
golang 错误处理适合一般的团队，团队成员层次不齐的情况下依然保证不会在错误处理上面出重大问题。
java 异常会被参差不齐的开发人员滥用。所以，只有那些真正理解异常并正确使用异常的人，才有权利说 java 异常用得爽、go 的繁琐。
golang 槽点太少？你怎么好意思说。
错误处理、泛型、duck typing 、编译时不严格检查、零值初始化、关键词过度复用、unused variable/import 该是 warning 非要当 error，等等。网络上成千上万字批判 go 的文章一大堆。
你说你觉得满意没问题，毕竟人嘛自己自己看着舒服最重要，但它哪里称得上“另类”？这玩意儿除了突出一个简单无脑，我看不出有另类的地方，拿 product type 来表现天然 union 结构的东西，如果这也算是 good taste 的话。。。
我意思是作者从另外一个角度去看待你说的 taste, 或许他们认为这种 c 类似的方式比较简单直白所以算 good taste? 毕竟 go 的口号之一就是 simple and straight.
另外 taste 这个东西和别的东西权衡下来或许也没有那么重要? 当然如果有种完美语言又有 taste 又工程性很高有简单上手, 那当然是最好不过了. 不过目前看下来 swift 个各方面权衡不错的, 只不过框在 apple 的生态了, 其他领域还远着…
除了没有调用栈，唯一的缺点就是有点麻烦
一般 if err !=nil 在我写的 go 里面要占一半左右
曾经我也觉得没有调用栈调试会比较麻烦
不过事实证明只要 error 写的够详细
基本上错误打印出来就能大概知道怎么发生的了
同样是 google 开发的编程语言，dart 比 golang 看着顺眼多了
因为要维护一个 golang 项目，学了点皮毛，给我的感觉是 golang 在语言特性方面为了区别而区别，看着不伦不类的感觉。
不过对于 go 主力开发人员来说看多了应该也习惯了
#35 这个很简单啊<br>int i;<br>try{<br> i = Integer.valueof(index)<br>}catch(NumberFormatException e){<br> i = 0;<br>}<br>
#35 而且你给的这个例子就奇怪，都没做错误处理，正确的写法不应该是这样吗：<br>func foo(index string) {<br>i, err := strconv.Atoi(index)<br>if err!=nil{<br> i = 0<br>}<br>}<br><br>
因为不能保证这个方法在有 err 返回的时候，第一个返回值的就一定是你想要的 0 。
错，你看看 strconv.ParseInt 的文档就知道了。或者跑下这个程序，看看返回是不是 0 ？ https://play.golang.org/p/0dLcyPJFt32
我看你这个“普遍写法”是要爆大锅，你以为是 0，实际输入如果超出 64 位整数能表示的范围，那它返回的是最大可以表示的整数，如果这个返回值用在循环里，你的程序就要跑很久很久了。所以错误最好不要忽略，也不要认为返回错误时，其他返回值就是零值。很简单的例子，io.Reader.Read，返回 io.EOF 时，另一个返回值也可能非零。
上面一口一个 try catch 的 不用看你们的代码 我就知道充满各种错误
简单来说
如果说 if err != nil 的问题是丑
try catch 的问题就是没法写出对的代码
在Go语言社区中，关于错误处理的讨论确实一直比较热烈，有人觉得繁琐，而你觉得用得爽，这其实反映了Go语言错误处理机制的两面性。
Go语言的错误处理通过显式的error类型返回值来实现，这种方式确实增加了代码的明确性和可读性。每次函数调用后检查错误，可以让程序员清晰地知道哪里可能出现问题，并采取相应的处理措施。这种风格鼓励了防御性编程，有助于减少潜在的bug。
对于那些觉得Go语言错误处理繁琐的人，可能是因为他们还没有适应这种风格，或者是在处理大量错误时觉得代码显得冗余。不过，Go语言社区也在不断探索和改进错误处理的最佳实践。例如，使用if err != nil的快捷方式、错误包装（errors.Wrap/errors.Is/errors.As）以及更高级的错误处理库（如pkg/errors、go-errors等）来简化错误处理流程。
你觉得Go语言的错误处理用得爽，可能是因为你已经掌握了这种风格，并且能够利用它写出清晰、健壮的代码。你的体验也证明了Go语言错误处理机制的有效性，只要理解了它的设计理念，就能够写出高质量的代码。
总之，Go语言的错误处理机制虽然有其独特之处，但通过不断学习和实践，我们可以找到最适合自己的编程风格，并写出更好的代码。如果你对Go语言的错误处理还有其他疑问或想法，欢迎继续探讨。
