duanji9481 2017-09-03 15:10
浏览 61
已采纳

惯用的快乐之路

Suppose we have a function that returns some value and an error. What's the preferred way of handling the error and value declarations?

func example_a(data interface{}) (interface{}, error) {
    var err error
    var bytes []byte
    if bytes, err = json.Marshal(data); err != nil {
        return nil, err
    }
    // ... 
    return use(bytes), nil
}

func example_b(data interface{}) (interface{}, error) {
    if bytes, err := json.Marshal(data); err != nil {
        return nil, err
    } else {
        // ... 
        return use(bytes), nil
    }
}

func example_c(data interface{}) (result interface{}, err error) {
    var bytes []byte
    if bytes, err = json.Marshal(data); err != nil {
        return
    }
    // ... 
    return use(bytes), nil
}

func example_d(data interface{}) (interface{}, error) {
    bytes, err := json.Marshal(data)
    if err != nil {
        return nil, err
    }
    // ... 
    return use(bytes), nil
}

func example_dream(data interface{}) (interface{}, error) {
    if bytes, err ≡ json.Marshal(data); err != nil {
        return nil, err
    }
    // ... 
    return use(bytes), nil
}

Example A is clear, but it adds 2 extra lines. Moreover, I find that it's unclear why in this particular case we should use var, and at the same time := is not always appropriate. Then you want to reuse the err declaration somewhere down the line, and I'm not a big fan of splitting declaration and assignment.

Example B is using the if-declare-test language feature, which I surmise is encouraged, but at the same time you are forced to nest function continuation violating the happy-path principle, which too is encouraged.

Example C uses the named parameter return feature, which is something between A and B. Biggest problem here, is that if your code base is using styles B and C, then it's easy to mistake := and =, which can cause all kinds of issues.

Example D (added from suggestions) has for me the same kind of usage problem as C, because inevitably I run into the following:

func example_d(a, b interface{}) (interface{}, error) {
    bytes, err := json.Marshal(a)
    if err != nil {
        return nil, err
    }

    bytes, err := json.Marshal(b) //Compilation ERROR
    if err != nil {
        return nil, err
    }

    // ... 
    return use(bytes), nil
}

So depending on previous declarations I have to modify my code to either use := or =, which makes it harder to see and refactor.

Example Dream is what I kind of intuitively would have expected from GO - no nesting, and quick exit without too much verbosity and variable reuse. Obviously it doesn't compile.

Usually use() is inlined and repeats the pattern several times, compounding the nesting or split declaration issue.

So what's the most idiomatic way of handling such multiple returns and declarations? Is there a pattern I'm missing?

  • 写回答

1条回答 默认 最新

  • douzhui1972 2017-09-03 15:56
    关注

    If you look at lots of Go code you will find the following to be the usual case:

    func example(data interface{}) (interface{}, error) {
        bytes, err := json.Marshal(data)
        if err != nil {
            return nil, err
        }
        // ... 
        return use(bytes), nil
    }
    

    The declare and test if construct is nice in its place, but it is not generally apropriate here.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 ELGamal和paillier计算效率谁快?
  • ¥15 file converter 转换格式失败 报错 Error marking filters as finished,如何解决?
  • ¥15 ubuntu系统下挂载磁盘上执行./提示权限不够
  • ¥15 Arcgis相交分析无法绘制一个或多个图形
  • ¥15 关于#r语言#的问题:差异分析前数据准备,报错Error in data[, sampleName1] : subscript out of bounds请问怎么解决呀以下是全部代码:
  • ¥15 seatunnel-web使用SQL组件时候后台报错,无法找到表格
  • ¥15 fpga自动售货机数码管(相关搜索:数字时钟)
  • ¥15 用前端向数据库插入数据,通过debug发现数据能走到后端,但是放行之后就会提示错误
  • ¥30 3天&7天&&15天&销量如何统计同一行
  • ¥30 帮我写一段可以读取LD2450数据并计算距离的Arduino代码