dsorecdf78171 2017-03-15 21:08
浏览 33
已采纳

正确处理错误

Typically in Go you find the following convention:

res, err := thingThatCanError(arg)

if err != nil {
        // handle it
}

However, it's obvious this gets VERY unruly very quickly for a large number of these calls:

res, err := thingThatCanError(arg)

if err != nil {
        // handle it
}

res, err2 := thingThatCanError(arg)

if err2 != nil {
        // handle it
}

res, err3 := thingThatCanError(arg)

if err3 != nil {
        // handle it
}

There's more lines of boilerplate error handling than code! This website says to avoid this but does not give an example on how to clean up this smell. A useful example comes straight from the Go blog that shows us how to clean up a homogenous HTTP app with an error handler that makes sense.

But imagine each of these calls aren't homogenous, as in with the same "central idea", so a single "error handler struct" wouldn't make a lot of sense.

Is there a way to clean up this type of code smell with functions that don't "mesh together" nicely in terms of errors?

  • 写回答

1条回答 默认 最新

  • dongpengqin3898 2017-03-15 22:21
    关注

    Unfortunately there's sometimes no way around these patterns. You could use panic/defer as a makeshift try/catch system but the community looks down upon it.

    If statements in Go can be combined with assignments so

    err := thing.Do()
    if err != nil {
       return err
    }
    

    can become

    if err := thing.Do(); err != nil {
       return err
    }
    
    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥15 求螺旋焊缝的图像处理
  • ¥15 blast算法(相关搜索:数据库)
  • ¥15 请问有人会紧聚焦相关的matlab知识嘛?
  • ¥15 网络通信安全解决方案
  • ¥50 yalmip+Gurobi
  • ¥20 win10修改放大文本以及缩放与布局后蓝屏无法正常进入桌面
  • ¥15 itunes恢复数据最后一步发生错误
  • ¥15 关于#windows#的问题:2024年5月15日的win11更新后资源管理器没有地址栏了顶部的地址栏和文件搜索都消失了
  • ¥100 H5网页如何调用微信扫一扫功能?
  • ¥15 讲解电路图,付费求解