Panic & Recover

Panic & Recover

The Panic Signal (panic())

Concept: A built-in function that stops the ordinary flow of control and begins panicking.

• Setup: A panic can be triggered manually by the programmer or automatically by the runtime (e.g., out-of-bounds array access).
• Behavior: When a function panics, its execution stops immediately. However, any functions called with the defer keyword are still executed in LIFO (Last-In, First-Out) order. After the defers run, the program crashes with a stack trace.
• Why: To signal that a "stop-the-world" event has occurred that the program cannot logically continue from (like a missing configuration file or a corrupted database connection).

func main() {
    fmt.Println("Starting...")
    
    // This will stop execution immediately after defers
    panic("Critical failure: Database not found") 
    
    fmt.Println("This will never run")
}

The Recovery Mechanism (recover())

Concept: A built-in function that allows a program to regain control of a panicking goroutine.

• Behavior:

  • recover is only useful inside deferred functions.
  • During normal execution, a call to recover returns nil.
  • During a panic, a call to recover captures the value passed to panic and stops the termination process, allowing the program to continue.

• Why: It acts as a safety net for servers. For example, a single failing HTTP request shouldn't crash the entire web server; recover allows the server to stay alive and log the error.

func handleRequest() {
    defer func() {
        if r := recover(); r != nil {
            fmt.Println("Recovered from panic:", r)
        }
    }()

    fmt.Println("Processing...")
    panic("Unexpected bug!") // Execution jumps to the deferred function
}

Deferred Execution (defer)

Concept: Scheduling a function call to run immediately before the surrounding function returns.

• Behavior: Defers are executed even if a panic occurs. They are the "cleanup crew" of the Go world.
• Why: It ensures resources like files, sockets, or database connections are closed properly, regardless of whether the function finished successfully or crashed.

func readFile() {
    file := openFile("data.txt")
    defer file.Close() // Guaranteed to run even if logic below panics

    // ... read logic ...
}

Conceptual Workflow

Panic Propagation

Concept: The upward movement of a panic through the "Call Stack."

• Behavior: If a function panics and doesn't recover, the panic "bubbles up" to the caller. This continues until it reaches the top-level main function or a recover is hit.
• Setup: Project structure for a typical middleware recovery:

myapp/
├── main.go
├── server/
│   └── middleware.go  # Often contains the recover() logic
└── api/
    └── handlers.go    # Might trigger a panic

• Why: This ensures that errors aren't silently ignored. If you don't explicitly handle a catastrophic failure, Go ensures the program exits rather than running in an unstable state.

The Deferred Recovery Block

Concept: Using recover() inside a defer to catch a panic before it crashes the process.

• Setup: The recover function must be called directly inside a defer function. If you call it in a normal function outside of the deferral, it will always return nil and have no effect.
• Behavior:
  • The code starts executing.
  • A panic is triggered.
  • The runtime stops the normal execution and looks for defer functions.
  • The recover() call catches the panic value.
  • The panicking stops, and the code inside the defer block continues.
• Why: This is commonly used in Web Servers. If one specific user request causes a nil-pointer exception, you don't want your entire website to go offline for every other user.

package main

import "fmt"

func main() {
    fmt.Println("Server starting...")
    
    // 1. We schedule the recovery first
    safeExecution()
    
    fmt.Println("Server is still running and healthy!")
}

func safeExecution() {
    // 2. This 'defer' acts as the safety net
    defer func() {
        if r := recover(); r != nil {
            // 4. We caught the panic! 
            fmt.Printf("RECOVERED: Caught a panic with value: %v\n", r)
            fmt.Println("The program is now stable again.")
        }
    }()

    fmt.Println("Executing risky logic...")
    
    // 3. This triggers the panic
    riskyOperation()

    fmt.Println("This line will never be reached.")
}

func riskyOperation() {
    panic("BOOM! Something went wrong.")
}

Scope of Recovery

The Goroutine Barrier

Concept: A recover only works within the same Goroutine where the panic occurred.

• Behavior: If you start a new goroutine (go func() { ... }) and it panics, a recover in your main function will not catch it. The whole program will still crash.
• Why: In Go, goroutines are independent execution paths. Each path must manage its own "safety net" if you want to prevent a total crash.

Setup: Correct vs. Incorrect Recovery structure.

# Correct Pattern
go func() {
    defer recover() // Local safety net
    panic("internal error")
}()

# Incorrect Pattern (Will still crash)
defer recover() // Main safety net
go func() {
    panic("internal error") // Panic happens in a different "lane"
}()

The "Pitfalls" Guide

Even experienced developers can misuse Panic and Recover. Here are the most common conceptual traps to avoid when writing Go.

The "Try-Catch" Trap

Concept: Using Panic/Recover as a standard control flow for "normal" errors.

• Behavior: A newbie might use panic for a missing file because it's "easier" than passing errors up the stack.
• Why: This is considered anti-pattern in Go. It makes the code harder to read and breaks the "Errors as Values" philosophy. Go expects you to handle errors explicitly so the flow is predictable.
• Correction: Always return an error unless the program literally cannot continue (e.g., a critical dependency is missing at startup).

The Silent Recovery

Concept: Recovering from a panic without logging or reporting what happened.

• Behavior: Calling recover() and then doing nothing with the output.
• Why: This creates "Zombie Processes"—the application is running, but it's in an unstable or corrupted state, and you have no idea why because the error was swallowed.
• Correction: At a minimum, always log the recovered value and the stack trace so you can debug the root cause later.

defer func() {
    if r := recover(); r != nil {
        // WRONG: log.Println("Something happened")
        // RIGHT: log.Printf("CRITICAL: Recovered from panic: %v\nStack: %s", r, debug.Stack())
    }
}()

The Deferred Panic

Concept: Triggering a panic inside a deferred function that is already handling a panic.

• Behavior: A function panics, the defer runs to clean up, but the cleanup code (like closing a database) also panics.
• Why: The new panic will replace the original panic, making it nearly impossible to debug what the first problem was.
• Correction: Ensure your deferred cleanup logic is robust and handles its own errors gracefully.

Summary & Best Practices

The "When to Use" Decision Tree

Concept: A mental framework for choosing the right error-handling strategy.

• Scenario A: The user entered an invalid password. Return an error.
• Scenario B: A required environment variable is missing at startup. Call panic().
• Scenario C: You are writing a library and want to ensure a bug in your code doesn't crash the user's entire app. Use recover() at the library boundary.

Reference Guides & Cheat Sheet

The Logic Matrix: Panic vs. Error

In Go, choosing between an error and a panic is a matter of intent.

Core Concepts Summary

This table explains the "Moving Parts" of Go's exception-like system.

The Golden Rules of Recovery

If you are implementing a recovery mechanism, keep these four conceptual constraints in mind:

• Rule 1: The Defer Requirement recover() only works inside a deferred function. Calling it anywhere else will return nil and do nothing.
• Rule 2: Capture the Value recover() returns the interface value that was passed into panic(). You can use this to log the specific error message.
• Rule 3: Resume Point After a successful recover(), execution does not go back to where the panic happened. It resumes at the end of the function that contained the defer.
• Rule 4: Goroutine Isolation A panic in one Goroutine must be recovered within that same Goroutine. You cannot catch a panic from a different concurrent thread.