dskzap8756
2016-04-09 14:21
浏览 312
已采纳

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

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

图片转代码服务由CSDN问答提供 功能建议

在Go中,是否可以仅使用函数返回?

例如,我要检查错误,而不是重复if语句,而是要调用诸如 checkErrors(err)之类的函数。

此处 是一个示例( goplayground

  func  foob​​ar(str字符串)err {
 _,err:= ioutil.ReadAll(resp.Body)
 checkError(err)//如果错误!= nil则foobar将返回err 
 / *如果err!= nil  {
 return err 
} * / 
} 
 
func checkError(err error){
 if err!= nil {
 //然后使函数在返回err中被调用。
  } 
} 
   
 
  • 写回答
  • 好问题 提建议
  • 关注问题
  • 收藏
  • 邀请回答

2条回答 默认 最新

  • duanpei8853 2016-04-09 14:52
    已采纳

    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.

    已采纳该答案
    评论
    解决 无用
    打赏 举报
  • doujiao1814 2016-04-09 16:23

    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)
    }
    
    评论
    解决 无用
    打赏 举报

相关推荐 更多相似问题