What are the differences in outcome for panic vs log.Fatalln()?
From the documentation on log.Fatalln():
func Fatalln(v ...interface{}) Fatalln is equivalent to Println() followed by a call to os.Exit(1).
The source code for Fatalln:
310 // Fatalln is equivalent to Println() followed by a call to os.Exit(1).
311 func Fatalln(v ...interface{}) {
312 std.Output(2, fmt.Sprintln(v...))
313 os.Exit(1)
314 }
It seems the main difference is whether or not the error is recoverable (since you can recover a panic) - is there anything more significantly different between these?
Panic's interface definition is:
215 // The panic built-in function stops normal execution of the current
216 // goroutine. When a function F calls panic, normal execution of F stops
217 // immediately. Any functions whose execution was deferred by F are run in
218 // the usual way, and then F returns to its caller. To the caller G, the
219 // invocation of F then behaves like a call to panic, terminating G's
220 // execution and running any deferred functions. This continues until all
221 // functions in the executing goroutine have stopped, in reverse order. At
222 // that point, the program is terminated and the error condition is reported,
223 // including the value of the argument to panic. This termination sequence
224 // is called panicking and can be controlled by the built-in function
225 // recover.
226 func panic(v interface{})
It appears panic does not return anything.
Is that the primary difference? Otherwise, they seem to perform the same function in an application, assuming the panic is not recovered.
The log message goes to the configured log output, while panic is only going to write to stderr.
Panic will print a stack trace, which may not be relevant to the error at all.
Defers will be executed when a program panics, but calling os.Exit exits immediately, and deferred functions can't be run.
In general, only use panic for programming errors, where the stack trace is important to the context of the error. If the message isn't targeted at the programmer, you're simply hiding the message in superfluous data.
panic is often used in little programs to just terminate the program once an error appears you don't know how to handle or don't want to handle. The downside of panic is exactly that: it'll terminate the program (mostly, unless you use recover). It's generally not good to use panic unless you intend to recover from it or unless something has happened you really can't recover from at all nor where you can gracefully terminate the program otherwise. Consider for example an API that offers you functionality but that API secretly has a panic somewhere and you notice that your program terminates in production due to this. Thus, the "outward API" of whatever code you write should recover from panics and return an error instead. The same thing applies to anything that terminates the program.
However, os.Exit() can't be recovered from nor does it execute defers.
Follow WeChat
Success story sharing
t.Fatal/t.Fatalfvs log in tests when possible)Fataldoesn't execute defers is a huge problem IMO, I can't see how this makes it a viable solution. For example because of that my program does not cleanup its temporary directories…log.Fatalis needed. Maybe?Fatalnot calling defer resulted in resources (like database) not being cleaned up. I think in general,Fatalshould be avoided in favor ofPanic. Only useFatalif you know for sure there's nodeferin the code including dependencies.