In Go, panic is a built-in function that signals an unrecoverable error or an
exceptional condition that should stop the normal execution flow of a program.
Unlike typical error handling (where functions return error values), panic is used for
situations where the program cannot reasonably continue or if there's a serious bug
that needs immediate attention.
Here's a detailed explanation of panic in Go:
What happens when panic is called:
1. Immediate Stop: When panic() is called, the normal execution of the current
function stops immediately. No code after the panic call in that function will be
executed.
2. Deferred Functions Execute: Any defer statements in the current function are
executed in Last-In, First-Out (LIFO) order. This is a crucial aspect of panic
because it allows for cleanup operations (like closing files or releasing locks)
even when a panic occurs.
3. Stack Unwinding: After the deferred functions in the current function
complete, the panic propagates up the call stack. The process repeats: the
calling function stops, its deferred functions are executed, and the panic
continues up the stack.
4. Program Termination: If the panic reaches the top of the goroutine's call stack
(e.g., the main function or the top-level function of a goroutine) and is not
"recovered" (explained below), the program terminates.
5. Output: When a program panics and terminates, it prints a "panic:" message
to standard error, followed by the value passed to panic() and a stack trace. The
stack trace shows the sequence of function calls that led to the panic, which is
invaluable for debugging. The program exits with a non-zero status (typically
exit code 2).
Syntax:
Go
func panic(v interface{})
The panic function takes an interface{} as an argument, meaning you can pass any
type of value to it (a string, an error, a custom struct, etc.) to describe the panic.
Examples of panic:
1. Explicitly calling panic:
Go
package main
import "fmt"
func divide(a, b int) int {
if b == 0 {
panic("division by zero") // Explicitly panicking
}
return a / b
}
func main() {
[Link]("Before division")
result := divide(10, 0) // This will cause a panic
[Link]("After division:", result) // This line will not be reached
}
Output:
Before division
panic: division by zero
goroutine 1 [running]:
[Link](0xa, 0x0)
/path/to/your/[Link] +0x2b
[Link]()
/path/to/your/[Link] +0x3a
exit status 2
2. Runtime Panics (Implicit Panics): Go's runtime can also trigger panics for
certain unrecoverable errors. These are usually indicative of programming
mistakes.
• Nil pointer dereference:
Go
package main
import "fmt"
func main() {
var s *string // s is nil
[Link](*s) // Panics here
}
• Index out of bounds:
Go
package main
import "fmt"
func main() {
arr := []int{1, 2, 3}
[Link](arr[5]) // Panics here
}
• Type assertion failure:
Go
package main
import "fmt"
func main() {
var i interface{} = "hello"
s := i.(int) // Panics here, cannot assert string to int
[Link](s)
}
When to use panic (and when not to):
The Go proverb is "Don't panic," which generally means that panic should be used
sparingly. Most errors in Go should be handled by returning an error value.
Appropriate uses for panic:
• Unrecoverable program bugs/logic errors: If your program enters a state
that should never happen according to its design, and there's no way to
gracefully recover, a panic can be used to indicate a serious bug that needs
fixing. Examples include:
• Failing to initialize a critical component.
• Violating fundamental invariants of your data structures.
• Reaching a default case in a switch statement that should theoretically
be unreachable.
• During development/prototyping: Sometimes you might use panic("not
implemented yet") as a temporary placeholder for features that aren't built, or
for immediate feedback during testing.
• "Fail-fast" behavior: In some server applications, if a critical dependency (like
a database connection) fails at startup, you might choose to panic to prevent
the server from starting in a broken state.
When to avoid panic (and use error instead):
• Expected errors: Most common errors, like file not found, network timeouts,
invalid user input, or database connection issues, should be handled with error
returns. These are conditions that you anticipate and can design your program
to handle gracefully.
• API design: If you're designing a library or package for others to use, it's
generally considered bad practice to have your public functions panic. Panics
will terminate the user's program, which is usually not what they want. Instead,
return error values, allowing the caller to decide how to handle the error.
Interaction with defer and recover:
The panic mechanism is designed to work in conjunction with defer and recover.
• defer: As mentioned, deferred functions always run when a function exits, even
if it's due to a panic. This is crucial for cleanup.
• recover: The recover built-in function is specifically designed to "catch" a panic.
It's only useful when called inside a deferred function. If recover is called in a
deferred function during a panic, it stops the unwinding process, returns the
value that was passed to panic, and the program resumes normal execution
after the deferred function.
Example of panic and recover:
Go
package main
import "fmt"
func protect(fn func()) {
defer func() {
if r := recover(); r != nil {
[Link]("Recovered from panic:", r)
}
}()
fn()
}
func troublesomeFunction() {
[Link]("Inside troublesomeFunction")
panic("Something really bad happened!") // This will cause a panic
[Link]("This line will not be executed")
}
func main() {
[Link]("Main function started")
protect(troublesomeFunction) // Call troublesomeFunction wrapped in protect
[Link]("Main function continued after potential panic")
// Example of another panic without recover
// func() {
// panic("Another unrecovered panic!")
// }()
[Link]("Main function finished")
}
Output:
Main function started
Inside troublesomeFunction
Recovered from panic: Something really bad happened!
Main function continued after potential panic
Main function finished
In this example, troublesomeFunction panics. However, because it's called within
protect which uses defer and recover, the panic is caught, the program doesn't crash,
and execution continues in main.
In summary:
panic in Go is a powerful mechanism for handling truly exceptional, unrecoverable
errors or logic bugs that indicate a fundamental flaw in the program's design. It's a
"crash-or-fix" signal. For expected error conditions, Go's idiomatic approach is to
return error values. The defer and recover functions provide a way to control the flow
of execution and potentially resume a program after a panic, though this should be
used judiciously, often at the boundaries of large systems (like a web server handling
individual requests) to prevent a single faulty request from crashing the entire server.