Go exception handling defer, panic, recover

This is a creation in Article, where the information may have evolved or changed.

The go language pursues simplicity and elegance, so the go language does not support the exception of traditional try...catch...finally, because the designers of the go language think that mixing exceptions with control structures can easily confuse the code. Because developers are prone to abuse exceptions, even a small error throws an exception. In the Go language, return errors using multivalued returns. Do not use exceptions to replace errors, not to control processes. In very rare cases, that is, when a real exception is encountered (such as a divisor of 0). Before using the exception process introduced in go: defer, panic, recover.

These unusual usage scenarios can be described as simple: go can throw a panic exception, then catch the exception in defer with recover and then handle it normally.

Example code:

package mainimport "fmt"func main(){    defer func(){ // 必须要先声明defer，否则不能捕获到panic异常        fmt.Println("c")        if err:=recover();err!=nil{            fmt.Println(err) // 这里的err其实就是panic传入的内容，55        }        fmt.Println("d")    }()    f()}func f(){    fmt.Println("a")    panic(55)    fmt.Println("b")    fmt.Println("f")}

Output Result:

A
C
55
D
Exit code 0, process exited normally.

Reference: http://blog.csdn.net/ghost911_slb/article/details/7831574

Defer

Defer English original meaning: VI. Defer, postpone, obey Vt. Make a postponement of; postpone.

Defer's ideas are similar to destructors in C + +, but the "destructor" in the Go language is not an object, but a function, and defer is the statement to be executed at the end of a function. Note that the emphasis here is on adding, not specifying, since destructors in C + + are static, and defer in Go is dynamic.

func f() (result int) {  defer func() {    result++  }()  return 0}

The above function returns 1 because defer adds a function that changes the value of the named return value before the function returns. is not very useful. However, it should be noted that if our defer statement is not executed, then the defer function will not be added, if the above program is changed to this:

func f() (result int) {  return 0  defer func() {    result++  }()  return 0}

The above function returns 0 because the function has not yet been added to the defer.

It is also worth mentioning that defer can be multiple times to form a defer stack, after which the defer statement is called first when the function returns.

Reference: http://weager.sinaapp.com/?p=31

Panic

Panic English original meaning: N. Panic, adj, panic, fear, no reason, Vt. Make Panic VI. Very alarmed.

The panic is used to indicate a very serious unrecoverable error. In the go language this is a built-in function that receives a value of type interface{} (that is, any value) as a parameter. The panic function is like the anomaly of our usual contact. However, go is not try...catch, so panic generally causes the program to hang (unless recover). So, the exception in the go language, that's really abnormal. You can try, call panic to see, the program immediately hangs, and then the go Run will print out the call stack.

However, the key point is that even when the function is panic, the function does not go down, the runtime is not immediately upward transfer panic, but to defer that, and so defer things are running out, panic and then passed upward. So this time defer a bit like the finally in try-catch-finally.

Panic is so simple. Throws a true sense of exception.

Recover

Recover English Original: Vt. To recover from, to make up for or regain VI. To regain the ball N. Revert to a ready posture

As mentioned above, panic's function does not return immediately, but defer first and then returns. At this time (defer), if there is a way to capture panic, and prevent panic transmission, then the exception of the processing mechanism is perfect.

The go language provides the recover built-in function, mentioned earlier, once panic, logic will go to defer that, then we wait in the defer, the call recover function will capture the current panic (if any), the captured panic will not be passed up, Thus, the world resumed peace. You can do what you want to do.

However, it is important to note that after recover, the logic does not revert to the panic point, and the function will return after the defer.

There is an example of using go to implement exception handling like Try catch in:

http://www.douban.com/note/238705941/

Conclusion:

The way go treats anomalies (exactly panic) is that it does not negate the existence of anomalies and strongly discourages the use of multiple exceptions.

Reference: http://blog.dccmx.com/2012/01/exception-the-go-way/

http://kejibo.com/golang-exceptions-handle-defer-try/

http://bookjovi.iteye.com/blog/1335282

Https://github.com/astaxie/build-web-application-with-golang/blob/master/02.3.md