Go language pursues simplicity and elegance, so Go language does not support the traditional try...catch...finally exception, because the designers of Go language believe that, Mixing exceptions with control structures can easily clutter your code.
Because developers can easily abuse exceptions, throwing an exception even for a small mistake. In Go language, multiple values are used to return errors. Don't use exceptions to replace errors, let alone control the process. In rare cases, that is, when a real exception is encountered (such as the divisor is 0). Only use the Exception handling introduced in Go: defer, panic, recover.
The usage scenarios of these exceptions can be described simply: Go can throw a panic exception, then capture the exception through recover in defer, and then handle it normally.
Example code:
package main import "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.
defer
defer Original English meaning: vi. To postpone; to postpone; to obey vt. To postpone; to postpone.
The idea of defer is similar to the destructor in C, but in the Go language, what is "destructed" is not the object, but the function. Defer is used to add statements that are executed when the function ends. Note that the emphasis here is on adding, not specifying, because unlike the destructor in C which is static, the defer in Go is dynamic.
func f() (result int) { defer func() { result++ }() return 0 }
The above function returns 1 because a function is added to defer and the value of the named return value is changed before the function returns. Isn’t it very useful? However, it should be noted that if our defer statement is not executed, 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 will return 0, because there is still The function returned before I had time to add defer.
It is also worth mentioning that defer can be performed multiple times, thus forming a defer stack, and the subsequent defer statements will be called first when the function returns.
panic
##panic Original English meaning: n. Panic, panic; panic adj. Panic; no reason vt. To panic vi . Very panicpanic is used to indicate a very serious and 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 function of panic is just like the exceptions we usually come into contact with. However, Go does not have try...catch, so panic will generally cause the program to hang (unless it is recovered). Therefore, exceptions in the Go language are really exceptions. You can try calling panic to see if the program hangs immediately, and then the call stack will be printed out when Go is running.However, the key point is that even if the function panics when it is executed, the function does not go down. The panic is not immediately passed upward during runtime, but to defer. When all the things in defer are finished, panic will occur again. Pass upward. So at this time defer is somewhat similar to finally in try-catch-finally.
panic is that simple. Throw a real exception.
recover
recover Original English meaning: vt. to recover; to make up for; to regain vi. to recover; to win; to regain the ball n. to restore to Preparatory postureAs mentioned above, the panic function does not return immediately, but defers first and then returns. At this time (during defer), if there is a way to capture the panic and prevent the panic from being delivered, then the exception handling mechanism will be perfect. Go language provides the recover built-in function. As mentioned earlier, once panic occurs, the logic will go to defer, then we will wait at defer. Calling the recover function will capture the current panic (if If so), the captured panic will not be passed upwards, and peace will be restored to the world. You can do what you want. However, it should be noted that after recovery, the logic will not be restored to the panic point, and the function will still return after defer. Conclusion: Go's attitude towards exceptions (panic to be precise) is this. It does not completely deny the existence of exceptions, and at the same time, it strongly discourages the use of exceptions.The above is the detailed content of Introduction to exception handling in go language. For more information, please follow other related articles on the PHP Chinese website!