《Go 1.13中的错误处理》的评论 https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/ 一个程序员的心路历程 Wed, 25 Mar 2026 09:21:20 +0000 hourly 1 http://wordpress.org/?v=3.2.1 作者：bigwhite https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/#comment-7679 bigwhite Tue, 21 Feb 2023 09:38:53 +0000 https://tonybai.com/?p=2792#comment-7679 Unwrap method returns []error ，这个是Go 1.20才增加的吧。 Unwrap method returns []error ，这个是Go 1.20才增加的吧。

]]> 作者：rogge https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/#comment-7678 rogge Tue, 21 Feb 2023 07:42:20 +0000 https://tonybai.com/?p=2792#comment-7678 一个小细节，补充一下，就是官方关于errors.Unwrap的注释是Unwrap returns nil if the Unwrap method returns []error. 即返回nil还有一种情况是Unwrap返回值是[]error的时候，比如fmt.Errorf语句中有多个%w时，Unwrap对该语句的返回值作用后也是返回nil 一个小细节，补充一下，就是官方关于errors.Unwrap的注释是Unwrap returns nil if the Unwrap method returns []error. 即返回nil还有一种情况是Unwrap返回值是[]error的时候，比如fmt.Errorf语句中有多个%w时，Unwrap对该语句的返回值作用后也是返回nil

]]> 作者：bigwhite https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/#comment-7390 bigwhite Mon, 04 Nov 2019 22:47:34 +0000 https://tonybai.com/?p=2792#comment-7390 1.13中只是解决了 Error value（及error链中值）判断的问题。整体的Error handling框架并未有改进。之前关于error handling的机制在加入go 1.13之前被社区否了。估计还要重新设计和讨论。 1.13中只是解决了 Error value（及error链中值）判断的问题。整体的Error handling框架并未有改进。之前关于error handling的机制在加入go 1.13之前被社区否了。估计还要重新设计和讨论。

]]> 作者：anko https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/#comment-7389 anko Mon, 04 Nov 2019 17:44:52 +0000 https://tonybai.com/?p=2792#comment-7389 个人没觉得彻底消除了之前的if err != nil{}的代码，只是给错误加了点分组和具体类型值判断，并没有根治多多错误处理的代码的冗余风格！！！这是很失败的设计！还是一样的！根本没改变，不看好go2,看好try....catch....这种。。。本人愚钝，对于go的设计，我想我考虑用装饰器去掉这种无聊的设计！几乎我写100行go代码中，错误处理占领了我40行+的代码，go都出来10年了，还是谷歌出品，如今却说热不热，说不热有点热的程度，却是值得go设计者深思！现在我的首选语言不会是go,只要不是特别要求性能，我都不会采用他，他对我来说是一门糟糕的语言！我更加喜欢python!虽然我只学习了go 3个月，但是就我目前对go库的了解，go需要彻底重写！go库写的很一般，有些api命名不搭调！例子我就不举了！我几乎遍历了一次go的所有库和浏览了一遍go的源码，源码写的很一般！很c范！如果可以选择，我不会成为go的提倡者！go结构体确实是明晰，但是却搭配如此不明晰的错误处理，他使的我的代码逻辑充斥着各种错误处理！这不是我想要的！ 个人没觉得彻底消除了之前的if err != nil{}的代码，只是给错误加了点分组和具体类型值判断，并没有根治多多错误处理的代码的冗余风格！！！这是很失败的设计！还是一样的！根本没改变，不看好go2,看好try….catch….这种。。。本人愚钝，对于go的设计，我想我考虑用装饰器去掉这种无聊的设计！几乎我写100行go代码中，错误处理占领了我40行+的代码，go都出来10年了，还是谷歌出品，如今却说热不热，说不热有点热的程度，却是值得go设计者深思！现在我的首选语言不会是go,只要不是特别要求性能，我都不会采用他，他对我来说是一门糟糕的语言！我更加喜欢python!虽然我只学习了go 3个月，但是就我目前对go库的了解，go需要彻底重写！go库写的很一般，有些api命名不搭调！例子我就不举了！我几乎遍历了一次go的所有库和浏览了一遍go的源码，源码写的很一般！很c范！如果可以选择，我不会成为go的提倡者！go结构体确实是明晰，但是却搭配如此不明晰的错误处理，他使的我的代码逻辑充斥着各种错误处理！这不是我想要的！

]]> 作者：bigwhite https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/#comment-7388 bigwhite Mon, 21 Oct 2019 11:32:51 +0000 https://tonybai.com/?p=2792#comment-7388 我觉得严谨的设计者不会要求去判断返回的结构体指针是否为nil的。只需判断返回的error是否为nil。一旦error为nil，则暗示返回的结构体指针是有效的。反之，一旦err != nil，则说明返回的结构体指针是无效的，不应该使用。其实类似的例子很多，比如函数返回(int, err)，当err !=nil时，我们也不应该去使用返回的int，这时的int处于无效状态。因此你说的问题的关键其实是api设计者的问题，他不应该要求对两个返回值都进行非nil判断。 我觉得严谨的设计者不会要求去判断返回的结构体指针是否为nil的。只需判断返回的error是否为nil。一旦error为nil，则暗示返回的结构体指针是有效的。反之，一旦err != nil，则说明返回的结构体指针是无效的，不应该使用。其实类似的例子很多，比如函数返回(int, err)，当err !=nil时，我们也不应该去使用返回的int，这时的int处于无效状态。因此你说的问题的关键其实是api设计者的问题，他不应该要求对两个返回值都进行非nil判断。

]]> 作者：voidint https://tonybai.com/2019/10/18/errors-handling-in-go-1-13/#comment-7387 voidint Sun, 20 Oct 2019 07:08:57 +0000 https://tonybai.com/?p=2792#comment-7387 一个函数的返回值是'结构体指针+error'，如果函数的实现者要求调用方在调用该函数后需要同时对这两个返回值做非nil判断（即使error为nil，结构体指针也同样有可能为nil），请问您怎么看待这样的设计？ 如果把标准库当作教科书，那以我这点浅薄的修为，还没有在这本教科书中找到这样的先例，那据您所知是否有这样的先例？ 一个函数的返回值是’结构体指针+error’，如果函数的实现者要求调用方在调用该函数后需要同时对这两个返回值做非nil判断（即使error为nil，结构体指针也同样有可能为nil），请问您怎么看待这样的设计？

如果把标准库当作教科书，那以我这点浅薄的修为，还没有在这本教科书中找到这样的先例，那据您所知是否有这样的先例？

]]>