哪个对我更好：“ defer-panic-recover”或在golang中检查“ if err！= nil {// dosomething}”？

问题描述：

I've made a large program that opens and closes files and databases, perform writes and reads on them etc among other things. Since there no such thing as "exception handling in go", and since I didn't really know about "defer" statement and "recover()" function, I applied error checking after every file-open, read-write, database entry etc. E.g.

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

For this, I define db_updation_status at the beginning as "false" and do not make it "true" until everything in the program goes right. I've done this in every function, after every operation which I believe could go wrong.

Do you think there's a better way to do this using defer-panic-recover? I read about these here http://golang.org/doc/articles/defer_panic_recover.html, but can't clearly get how to use them. Do these constructs offer something similar to exception-handling? Am I better off without these constructs? I would really appreciate if someone could explain this to me in a simple language, and/or provide a use case for these constructs and compare them to the type of error handling I've used above.

我制作了一个大型程序，用于打开和关闭文件和数据库，对文件和数据库执行写入和读取等操作。的东西。由于没有“进行异常处理”之类的事情，并且由于我对“ defer”语句和“ recover（）”函数一无所知，因此我在每次打开文件，读写，数据库输入后都进行错误检查等等 p>

  _，insert_err：= stmt.Run（query）
if insert_err！= nil {
 mylogs.Error（insert_err.Error（））
返回 db_updation_status 
} 
  code>  pre> 
 
 为此，我在开始时将db_updation_status定义为“ false”，直到程序中的所有内容都正确之后才将其设置为“ true”。  
在我认为可能会出错的每个操作之后，我已经在每个函数中完成了此操作。 p> 
 
 
您认为使用defer-panic-recover有更好的方法吗？ 我在这里 http://golang.org/doc/articles/defer_panic_recover.html，但不清楚如何使用它们。 这些构造是否提供类似于异常处理的功能？ 如果没有这些构造，我会更好吗？
如果有人可以用一种简单的语言向我解释这一点，并且/或者提供这些构造的用例并将它们与我上面使用的错误处理类型进行比较，我将非常感谢。   p> 
  div>

答

It's more handy to return error values - they can carry more information (advantage to the client/user) than a two valued bool.

What concerns panic/recover: There are scenarios where their use is completely sane. For example, in a hand written recursive descent parser, it's quite a PITA to "bubble" up an error condition through all the invocation levels. In this example, it's a welcome simplification if there's a deferred recover at the top most (API) level and one can report any kind of error at any invocation level using, for example

panic(fmt.Errorf("Cannot %v in %v", foo, bar))

答

If an operation can fail and returns an error, than checking this error immediately and handling it properly is idiomatic in go, simple and nice to check if anything gets handled properly.

Don't use defer/recover for such things: Needed cleanup actions are hard to code, especially if stuff gets nested.

答

The usual way to report an error to a caller is to return an error as an extra return value. The canonical Read method is a well-known instance; it returns a byte count and an error. But what if the error is unrecoverable? Sometimes the program simply cannot continue. For this purpose, there is a built-in function panic that in effect creates a run-time error that will stop the program (but see the next section). The function takes a single argument of arbitrary type—often a string—to be printed as the program dies. It's also a way to indicate that something impossible has happened, such as exiting an infinite loop.

http://golang.org/doc/effective_go.html#errors

哪个对我更好：“ defer-panic-recover”或在golang中检查“ if err！= nil {// dosomething}”？

相关推荐