英文:
Return a Value Using Another Function with Golang?
问题
在Go语言中,可以通过函数来实现返回操作吗?
例如,我想检查错误,而不是重复使用if语句,我只想调用一个名为checkErrors(err)
的函数。
以下是一个示例(goplayground):
func foobar(str string) err {
_, err := ioutil.ReadAll(resp.Body)
checkError(err) // 如果error != nil,则foobar将返回该错误
/*if err != nil {
return err
}*/
}
func checkError(err error) {
if err != nil {
// 然后使调用该函数的函数返回该错误。
}
}
英文:
In Go, is it possible to return using a function only?
For example, I want to check for errors and instead of repeating an if statement, I want to just call a function such as checkErrors(err)
.
Here is an example (goplayground)
func foobar(str string) err {
_, err := ioutil.ReadAll(resp.Body)
checkError(err) // If error != nil then foobar will return the err
/*if err != nil {
return err
}*/
}
func checkError(err error) {
if err != nil {
// Then make the function this is being called within return the err.
}
}
答案1
得分: 1
你的导师是正确的:不要重复代码。这被称为“不要重复自己(DRY)原则”。
但Go语言的设计者在设计语言时采取了不同的方向。这导致了开发社区的分裂,引发了争论,甚至扭曲了时空。
其中一个方向是为了让代码更易读而接受少量的复制。正如你已经注意到的,错误处理就是其中之一。它鼓励在整个应用程序中重复检查nil的模式,而不是将真正的错误处理抽象化(并且可以轻松地忽略)。
Rob Pike在他的Go语言设计(和哲学)演讲中提到了这个方向:
http://talks.golang.org/2012/splash.article
>如果错误使用特殊的控制结构,错误处理会扭曲程序的控制流。类似Java的try-catch-finally块交织着多个重叠的控制流,它们以复杂的方式相互交互。尽管相比之下,Go语言更加冗长地检查错误,但明确的设计使得控制流保持简单直接。
并不是每个人都同意这一点,这也是争论的原因。
但是,这些决策打破了对开发人员施加的行业标准的负担,这正是他们这样做的原因:你被迫每次都要面对和处理每个错误。你不能忽视或让其他东西来处理它。
并不是每个人都同意这一点。
我强烈建议你和你的导师阅读一下关于Go语言设计的那篇文章。然后你们可以决定是否选择Go语言作为前进的方向。
英文:
Your tutor is correct: don't repeat code. It is called the DRY principal.
But the authors of Go have taken a different direction when designing the language. And it has fractured the development community, it has caused wars, it has warped space and time.
One of these directions is to accept a little bit of copying, to make the code easier to read. Error handling, as you have noticed, is one such area. It invites a little repetitous pattern of checking for nil all over your app instead of abstracting away (and easily able to ignore) the true error handling you should be doing.
Rob Pike addressed this direction in his Design (and Philosophy) of GoLang talk:
http://talks.golang.org/2012/splash.article
>If errors use special control structures, error handling distorts the control flow for a program that handles errors. The Java-like style of try-catch-finally blocks interlaces multiple overlapping flows of control that interact in complex ways. Although in contrast Go makes it more verbose to check errors, the explicit design keeps the flow of control straightforward—literally.
Not everyone agrees and it's why wars are started.
But, these decisions to shake up the industry standards that has put so much if a burden on developers is exactly why they are doing it: you are forced to deal with each error up front and center, every time. You cannot ignore or let something else handle it.
Not everyone agrees.
I highly suggestion you and your Tutur read that post about the design of Go. Then you two can make the decision of rather Go is the way to Go or not.
答案2
得分: 1
只是为了补充已经很好的答案,你可以使你的checkError
函数更加定制化,这样你可以在一开始处理错误的同时保持DRY原则:
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)
}
英文:
Just to add to the already great answer, you can make your checkError
function more customized, so you get to still deal with the error up front while still keeping it DRY:
func checkError(err error, handler func(e error)) {
if err != nil {
handler(err)
}
}
This way you can pass in the handler function you want to use with each error without forgetting the responsibility while saving two lines of repetitive error-handling code.
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)
}
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论