Golang's log. Differences between the Fatal () and Panic () functions

Golang's log. Differences between the Fatal () and Panic () functions

Let's look at the OS before we tell the difference. The definition of the Exit () function:

func Exit(code int)Exit causes the current program to exit with the given status code.Conventionally, code zero indicates success, non-zero an error.The program terminates immediately; deferred functions are not run.

Note two points:

1. The application exits immediately.
2. The defer function does not execute.

Look at log again. Fatal function definition

func Fatal(v ...interface{})Fatal is equivalent to Print() followed by a call to os.Exit(1).

See Source code: Go/src/log/log.go

// Fatal is equivalent to l.Print() followed by a call to os.Exit(1).func (l *Logger) Fatal(v ...interface{}) {    l.Output(2, fmt.Sprint(v...))    os.Exit(1)}

Sum up log. The fatal function is complete:

1. Print out content
2. Exit application
3. The defer function does not perform

and OS. Exit () is more than the first step.

Then look at the built-in function panic () function definition:

// The panic built-in function stops normal execution of the current// goroutine. When a function F calls panic, normal execution of F stops// immediately. Any functions whose execution was deferred by F are run in// the usual way, and then F returns to its caller. To the caller G, the// invocation of F then behaves like a call to panic, terminating G's// execution and running any deferred functions. This continues until all// functions in the executing goroutine have stopped, in reverse order. At// that point, the program is terminated and the error condition is reported,// including the value of the argument to panic. This termination sequence// is called panicking and can be controlled by the built-in function// recover.func panic(v interface{})

Note the points:

1. The function stops executing immediately (note that the function itself, not the application stops)
2. The defer function is executed
3. Returned to the caller (caller)
4. The caller function pretends to also receive a panic function, which
   4.1 Stop executing the current function immediately
   4.2 It defer function is executed
   4.3 returned to it by the caller (caller)
5. ... (recursion repeats the above steps until the topmost function)
   The application stops.
6. Panic's behavior

A simple summary of panic () is a bit like the Java language exception processing, so panic behavior and Java exception processing behavior is very similar to the behavior of the catch, and final statement block processing process.

Here are a few examples:

Example 1:log. Fatal

package mainimport (    "log")func foo() {    defer func () { log.Print("3333")} ()    log.Fatal("4444")}func main() {    log.Print("1111")    defer func () { log.Print("2222")} ()    foo()    log.Print("9999")}

Operation Result:

$ go build && ./main2018/08/20 17:48:44 11112018/08/20 17:48:44 4444

The contents of the defer function are visible and not executed, and the program is in log. Fatal (...) Exit directly from the office.

Example 2:panic () function

package mainimport (    "log")func foo() {    defer func () { log.Print("3333")} ()    panic("4444")}func main() {    log.Print("1111")    defer func () { log.Print("2222")} ()    foo()    log.Print("9999")}

Operation Result:

$ go build && ./main2018/08/20 17:49:28 11112018/08/20 17:49:28 33332018/08/20 17:49:28 2222panic: 4444goroutine 1 [running]:main.foo()        /home/.../main.go:9 +0x55main.main()        /home/.../main.go:15 +0x82

It can be seen that all defer are called, and the function is called to the top of all defer according to the parent-child invocation relationship.
Of course, if one of the layers functions defines the recover () function, then panic will be intercepted in that layer of function and then defined by recover () to handle the panic, discard it, or throw it up. (Is it the same as exception's handling mechanism?) )