2 回答

TA贡献1951条经验 获得超3个赞
你的导师是对的:不要重复代码。它被称为DRY 主体。
但是 Go 的作者在设计语言时采取了不同的方向。它破坏了开发社区,引发了战争,扭曲了空间和时间。
这些方向之一是接受一点点复制,使代码更易于阅读。 正如您所注意到的,错误处理就是这样一个领域。它邀请了一些重复的模式来检查整个应用程序中的 nil,而不是抽象掉(并且很容易忽略)您应该做的真正的错误处理。
Rob Pike 在他的 GoLang 设计(和哲学)演讲中谈到了这个方向:
http://talks.golang.org/2012/splash.article
如果错误使用特殊的控制结构,错误处理会扭曲处理错误的程序的控制流。类 Java 风格的 try-catch-finally 块交织多个重叠的控制流,这些控制流以复杂的方式交互。尽管相比之下 Go 使检查错误更加冗长,但显式设计使控制流保持直截了当——字面意思。
不是每个人都同意,这就是战争开始的原因。
但是,这些改变行业标准的决定给开发人员带来了巨大的负担,这正是他们这样做的原因:您每次都被迫提前和集中处理每个错误。你不能忽视或让其他东西来处理它。
并非所有人都同意。
我强烈建议您和您的 Tutur 阅读有关 Go 设计的帖子。然后你们两个可以决定宁Go是去还是不去。

TA贡献1843条经验 获得超7个赞
只是为了添加已经很好的答案,您可以使您的checkError功能更加个性化,因此您仍然可以预先处理错误,同时仍然保持干燥:
func checkError(err error, handler func(e error)) {
if err != nil {
handler(err)
}
}
通过这种方式,您可以传入要用于每个错误的处理程序函数,而不会忘记责任,同时节省两行重复的错误处理代码。
handler1 = func(e error) {
panic(e)
}
handler2 = func(e error) {
log.Fatal(e)
}
func foobar(str string) err {
_, err := ioutil.ReadAll(resp.Body)
checkError(err, handler2)
}
- 2 回答
- 0 关注
- 131 浏览
添加回答
举报