写了个 err warp，或许可以少写点 if err

[voidmnwzp]

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

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

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

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

[magicdawn]

@Nasei map_err / ok_or_else 啊

[magicdawn]

@Nasei

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

[voidmnwzp]

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

[fregie]

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

[fregie]

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

[voidmnwzp]

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

[ireina]

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