Go: What is the difference between log.Fatal and log.Panic?

log.Fatal — logs a message and calls os.Exit(1) (program terminates immediately). log.Panic — logs a message and calls panic() (deferred functions run).

log.Fatal behavior:

• Logs the message with timestamp.
• Calls os.Exit(1) immediately.
• Deferred functions are NOT executed.
• No way to recover.
• Program terminates with exit code 1.

1func main() {
2    defer fmt.Println("This will NOT print")
3    
4    if err := startServer(); err != nil {
5        log.Fatal("Failed to start server: ", err)
6    }
7}
8// Output: 2024/01/15 10:30:45 Failed to start server: connection refused
9// Deferred fmt.Println never runs
10// Program exits with code 1

log.Panic behavior:

• Logs the message with timestamp.
• Calls panic() with the formatted message.
• Deferred functions ARE executed.
• Can be recovered with recover().
• Unrecovered panic crashes the program.

1func main() {
2    defer func() {
3        if r := recover(); r != nil {
4            fmt.Println("Recovered:", r)
5        }
6    }()
7    
8    defer fmt.Println("This WILL print")
9    
10    log.Panic("Something went wrong")
11}
12// Output:
13// 2024/01/15 10:30:45 Something went wrong
14// This WILL print
15// Recovered: Something went wrong

When to use log.Fatal:

• Startup failures (missing config, port already in use).
• Critical errors where cleanup isn't needed.
• Simple programs where deferred cleanup isn't important.

When to use log.Panic:

• Errors that might be recoverable by a caller.
• Library code that needs to propagate errors upward.
• When you need deferred functions to run (cleanup, logging).

Common mistakes:

• Using log.Fatal in library code (forces caller to handle termination).
• Using log.Panic without a recover() somewhere up the stack.
• Forgetting that log.Fatal doesn't run deferred functions (data loss risk).
• Using either for normal error handling (prefer returning errors).
• Mixing log.Fatal with error returns (caller never sees the error).