问下go的错误处理风格选择

The Go Programming Language

Go Projects

This topic created in 4665 days ago, the information mentioned may be changed or developed.

if data, err := GetData(); err != nil {
//handle error
} else {
//bz job
}

还是
if data, err := GetData(); err == nil {
//bz job
} else {
//handler error
}

我倾向与把错误处理卸载前面，应为错误现在的错误处理都比较短。

问：
1. 哪种是普适好选择（如果有的话）？为什么？
2. 还是应该根据情景选择，考虑哪些因素？

Supplement 1 · Jun 25, 2015

现在我倾向于这么做：
在框架设计时，严格区分业务逻辑和框架核心逻辑。
业务逻辑特点是多变需要快速迭代；框架核心逻辑特点是一个字稳。

在设计上，业务逻辑一个允许脑残写，并应该不被核心逻辑信任（类似内核和用户进程的关系）

a) 业务逻辑代码应该设计上尽量不允许发生致命错误。
以 a 为前提下，我们可以在业务逻辑中使用 panic 做错误处理。
业务逻辑入口捕获业务逻辑产生的错误，并记录详细日志。

核心逻辑则应该尽量少隐瞒错误，应该认为正常情况下不会有任何错误。除非非常清楚吃掉的是什么错误（比如客户端连接 EOF 之类的）否则宁愿 panic 让整个进程死掉。

func some_bz() {
PanicIf(db == nil, "err msg")
}

func gateway() {
defer func() {
if err := recover(); err != nil {
switch err.(type) {
case FatalError: panic(err)
}
log()
}
}
some_bz()
}

err

错误处理

nil

14 replies • 1970-01-01 08:00:00 +08:00

suchj

Aug 21, 2013

我个人是这样做的，大部分函数都会带错误返回，因此：

if data, err := GetData(); err != nil {
//handle error
return
}

假如不需要错误返回，仅需错误处理，也是上面这种方式，没必要带一个 else，接着写正常的处理流程就行了，这样可以减少代码的嵌套层数，使代码更加清晰：

if data, err := GetData(); err != nil {
//handle error
}
//blabla...

具体可以参考 Go 编程语言的 12 条最佳实践：
http://www.oschina.net/news/42825/go-best-practices?from=20130804

reusFork

Aug 21, 2013

用第一种就不需要else了

chisj

Aug 21, 2013

异常处理一般都是写前面的，什么语言都一样。

rwx

Aug 21, 2013

先判断错误尽早返回
另外像
if data, err := GetData(); err != nil {
//handle error
return
}
这种形式data的作用域只是在if内部吧，后续完全没法利用到了
除非需要判断err，否则我一般写成
data, err := GetData()
if err != nil {
//handle error
return
}
dosomething(data)

rwx

Aug 21, 2013

#4 「除非需要判断err」->「除非只需要判断err」

sillyousu

Aug 21, 2013

@reusFork
这是公司的一个内部系统的代码。
现在的代码对某些错误只做了log，没有返回囧

其实我比较喜欢
data, err := GetData()
if err != nill {
//handle err & return
}
//bz job
这样写的。

janxin

Aug 21, 2013

data, err := GetData()
if err != nill {
//handle err & return
}

目前基本是这种方式，很多时候需要注意return，还好go里不用考虑释放什么的问题，否则弄不好就泄漏了

if err == nill {
....
}else{
//handle err & return
}
很多时候做容错情况下用，就是有些情况这样用比较好

RisingV

Aug 22, 2013

因为错误不是在所有地方都能进行处理的，等返回到可以处理的地方，你可能已经不知道错误是哪个地方来的。
这是go的末尾返回error的弊端所在，try/catch方式就能记录完整的调用栈。但是go的这种简洁的方式，很多时候也够用了。
作为弥补，可以自己写一套简单的库，在error返回时，封装更多的调用信息进去。这样排错的时候，可以节省很多功夫。