Golang Go语言中写了个 err warp，或许可以少写点 if err

一般情况下需要串行化的执行下去，如果其中一步遇到错误就会退出，但这样调用完个每个方法都要写个 err

png

如果将执行的方法作为一个闭包封装进去,就可以省去一大堆 if err：

png

这样如果执行的过程中遇到了错误,也会跳过执行， 最后调用 wrap.Error()返回错误 e.g.:

png

外层变量 a,b,c,d 可以通过闭包来赋值


Golang Go语言中写了个 err warp，或许可以少写点 if err

更多关于Golang Go语言中写了个 err warp，或许可以少写点 if err的实战教程也可以访问 https://www.itying.com/category-94-b0.html

48 回复

没变少啊……

更多关于Golang Go语言中写了个 err warp，或许可以少写点 if err的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


https://github.com/Yanjiachan/ErrorChain

这样怎么确定 err 是在哪一步抛出的？

你这写的比 if err 还多

还是 4 行一个啊

就我一个人喜欢写 if err ？简单直接

自己用用可以

这还不如用 defer 呢 有种用 java 面向对象打印 hello world 即视感

其实应该是 wrap?

没了 if err 的 golang 都没那味儿了

errors := map[string]string{
“a”: “a error”,
“b”: “b error”,
“c”: “c error”,
“d”: “d error”
}

rust 也是 err value ，但是有 unwrap 和 ？存在方便许多

<br><br>func Must[T any](T val, e error) T {<br> if e != nil {<br> painc(e)<br> }<br> return val<br>}<br><br><br>func Must2[T any, K any](T val1, K val2, e error) (T, K) {<br> if e != nil {<br> painc(e)<br> }<br> return val1, val2<br>}<br><br><br>

😓 哈哈哈哈，，搞混了

人才

你重新发明了那篇经典的 errors are values 博文中建议的实践。

https://go.dev/blog/errors-are-values

rust 是 value or error 不是 value and error


这篇经典博文也不过是在重新发明 result/either monad
也许这就是一种传承

一行没变少，反而增加几行初始化变量。。

不瞒你说 我就是看了 rob pike 写的 wrap 后才写的

与其叫少写，不如叫遮羞布。。。

#6 你不是一个人！喜欢 if err 的人多着呢，只是我都懒得喷那些喷 if err 的人罢了

github.com/pkg/errors

好像有个 multierr 包

觉得 if err != nil 让别人更容易搞懂程序每一步的错误想怎么处理…不明白为何要把它 warp 或者简化起来

字面意义上的过度封装。

https://github.com/hashicorp/go-multierror

虽然但是，为什么是 warp 不是 wrap

我也有做类似的处理

// WrapErrors 把多个错误合并为一个错误.
func WrapErrors(allErrors …error) (wrapped error) {
for _, err := range allErrors {
if err != nil {
if wrapped == nil {
wrapped = err
} else {
wrapped = fmt.Errorf("%w | %w", wrapped, err)
}
}
}
return
}

我这个使用时应该更直白简洁, 例如

a, err1 := func1()
b, err2 := func2()

if err := WrapErrors(err1, err2); err != nil { return err }

这时候不应该换语言了吗 🐶

if err 都没有，那还是 go 了吗？

想到个这个，大家看这样有什么问题不：
1. 定义一个函数 func checkError(err error)，函数内检查如果 err!=nil 就 panic(err)
2. 在你业务函数开头写一个 defer func()内部做 recover()
3. 在你业务函数中每次调用后，调用 checkError(err)

这样就不用写那么多if err != nil { ...了吧，panic 被捕获时，也能知道发生 err 的是啥。

是我第 2887 喜欢的 go boy 重新发明 monad 时间🤗

楼主要的效果是，有函数有错误，下面的代码就不执行了，你这个即使 func1 出错了，func2 还是会执行

可以是可以 这样就是类似 java 的 try/catch 但是，风险太大 万一哪个地方漏写了 recover 那不是单个 goruntine down 了 是个整个进程都得挂 一不小心就是线上重大事故了属于

因为我拼错了。z

没事，我也经常拼错🤣

如果不用库，rust 的 ? 在 Err 类型不一样的时候感觉很难受…



有编译器语法糖啊, Result<>? / Option<>? 会自动 check 是否是 err / 是否有值
不用库啊, go 可以学一下.

map_err / ok_or_else 啊



类型不一样这个…再怎么难受也比 go 机械地写 if err != nil 好吧, 本该是编译器做的事情却让开发者承担.

go2 会有语法糖的
比如
usr:=getUser
handle err{
return user{}
}

golang 都迭了这么多代了，仍然一点没改错误处理机制，大概谷歌那帮开发 golang 的专家没有这里的评论者考虑的周全吧，为什么不加 try-catch 呢？
从对 golang 的理解就可以看出各位到底是一位优秀的 coder 还是一位优秀的 engineer
coder 会从自己的角度出发，觉得写起来最方便最快的就是好的
engineer 会从工程的角度出发，考虑如何能让工程的效率和质量更好
现代大型软件的业务逻辑 bug ，绝大多数都是因为错误处理不得当导致的，各位 coder 不妨回想一下最近一年遇到的 bug ，是不是如此。
这种又臭又长的错误处理机制，虽然烦人，但是有效

我打赌没有，有这种语法糖 go 就废了

我认为 error is value 的设计并无不妥 只是实际业务中每一个 err 都需要去 if err 处理 太麻烦 不处理万一出现问题 那是找死都找不出来的

我也尝试过类似的事。我觉得没必要去改if err != nil其实，错误处理是一种计算效应，真正的干净的代码需要 monad ，但是目前没几个语言直接支持 monad 的上下文管理。把 error wrap 起来的确是一种处理错误的方式，标准库里其实也有使用过（但是很少），这种方式的缺点在于你必须很清楚 error 的状态是如何共享的。我觉得在给 interface 写 adapter 的时候可以用，但是平时写 struct 是不必要的。

在Go语言中，处理错误（error）是一个常见的任务，而编写简洁且有效的错误处理代码对于保持代码的可读性和可维护性至关重要。你提到的“err warp”（可能是指错误封装或包装）确实是一个常见的模式，用于在函数调用链中传递和处理错误。

为了减少if err语句的数量，你可以考虑以下几种方法：

  1. 使用命名返回值：在函数定义时，将错误作为命名返回值，这样你可以在函数体中直接返回错误，而无需显式的if err检查。

  2. 错误包装：在封装或包装错误时，使用fmt.Errorf或errors.Wrap（如果你使用pkg/errors包）来添加上下文信息。这样，在调用链的下游，你可以通过检查错误的类型或内容来做出决策，而不是仅仅依赖if err != nil。

  3. 延迟错误处理：在某些情况下，你可以将错误处理推迟到函数的末尾，使用defer语句和匿名函数来收集和处理错误。

  4. 使用辅助函数：编写辅助函数来处理常见的错误处理模式，如重试逻辑、日志记录等，以减少重复代码。

通过这些方法，你可以减少if err语句的数量，同时保持代码的清晰和有效。不过，请注意不要过度追求简洁而牺牲了代码的可读性和可维护性。在编写错误处理代码时，始终要考虑上下文和具体需求。

回到顶部