go - `Exit(1)` 到哪里,哪里返回错误?

标签 go error-handling idioms

处理发生在程序层深处的错误的惯用方法是什么?如果我在包的深处某处有这样的片段:

file, err := os.Open(path)
if err != nil {            
    os.Exit(1) // or return errors.New("The path is invalid.")
}                          

我是否应该返回一个错误并可能将它拖过几层 if {} else {} block 直到 mainExitmainExit 立即?

使用立即Exit 代码看起来更清晰、更易读。但有时很难测试。使用返回和检查代码看起来更糟(在我看来),但它更容易测试并达到 100% 的覆盖率。

还有一个问题...如果我正在编写一个包并且它没有 main 函数,我应该将 Exit 留给“用户”程序并且只是返回错误?

最佳答案

基本上,您最好就地处理错误,而不是通过药物来解决。当您需要立即退出时,您也可以调用 os.Exit()。你忘记了另一个选项 - panic()。它遍历并评估延迟函数,允许您进行一些拆解。在编写程序包时,不建议调用 os.Exit()panic() 以免让用户产生不可预测的混淆。在包中促进错误是最好的选择。

关于go - `Exit(1)` 到哪里,哪里返回错误?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41912264/

相关文章:

c# - ASP.NET MVC 4 错误处理

python - 在 Python 2.7 中处理超出范围的列表索引

Scala 2.10 - 八进制转义已弃用 - 现在如何惯用地执行八进制?

http - 无法在golang中使用socks5代理-读取: connection reset by peer

go - 管道到执行过程

go - 基于 mgo 中的正则表达式的搜索未给出所需的结果

excel - 如何为超过255个字符的范围创建验证列表

ruby - Ruby 中的哈希成语的哈希?

c++ - 如何表达 "the minimum integral type larger than T"?

c - 在 C/Go 中从 Google Chrome 获取标签页信息