在Golang中使用另一个函数返回值？

Question

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.
    }
}

Answer 1

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.