哪一个更适合我使用:"defer-panic-recover"或检查golang中的"if err!= nil {// dosomething}"?

pym*_*ymd 3 error-handling go panic

我做了一个大型程序,打开和关闭文件和数据库,执行写入和读取等等.由于没有"go中的异常处理"这样的事情,并且由于我并不真正了解"defer"语句和"recover()"函数,所以我在每次文件打开,读写,数据库输入后应用了错误检查等等

_,insert_err := stmt.Run(query)
if insert_err != nil{
    mylogs.Error(insert_err.Error())
    return db_updation_status
}
Run Code Online (Sandbox Code Playgroud)

为此,我在开头将db_updation_status定义为"false",并且在程序中的所有内容都正确之前不要将其设置为"true".在我认为可能出错的每次操作之后,我在每个功能中都这样做了.

你认为使用延迟 - 恐慌恢复有更好的方法吗?我在这里阅读了这些http://golang.org/doc/articles/defer_panic_recover.html,但无法清楚地了解如何使用它们.这些构造是否提供类似于异常处理的东西?没有这些结构,我会更好吗?如果有人能用一种简单的语言向我解释这个问题,并且/或者为这些结构提供一个用例并将它们与我上面使用的错误处理类型进行比较,我将非常感激.

zzz*_*zzz 6

返回错误值更方便- 它们可以携带比二值更多的信息(对客户端/用户有利)bool.

关注恐慌/恢复的问题:有些情况下他们的使用是完全正确的.例如,在手写的递归下降解析器中,通过所有调用级别"冒泡"错误条件是一个相当大的PITA.在这个例子中,如果在最顶层(API)级别存在延迟恢复并且可以在任何调用级别使用例如报告任何类型的错误,那么这是一种受欢迎的简化.

panic(fmt.Errorf("Cannot %v in %v", foo, bar))
Run Code Online (Sandbox Code Playgroud)

  • 包的另一个礼仪注意事项:包不应该"泄漏"恐慌,但总是从函数调用返回错误.如何处理包内的东西是你的选择,jnml的建议是一个很好的方法. (2认同)