Which one is better for me to use: "defer-panic-recover" or checking "if err != nil { //dosomething}" in golang?

Question

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.

Answer 1

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))

Answer 2

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.

Answer 3

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