---
title: Avoid Panic in Production
impact: HIGH
impactDescription: prevents application crashes and enables graceful degradation
tags: go, error-handling, stability, quality
---

## Avoid Panic in Production

Panic should be reserved for truly unrecoverable programmer errors (e.g., initialization failure where the app cannot start). Business logic and normal I/O should always use `error` returns.

**Incorrect (panic for normal errors):**

```go
func GetUser(id string) *User {
    user, err := db.Find(id)
    if err != nil {
        panic(err) // Crash!
    }
    return user
}
```

**Correct (return error):**

```go
func GetUser(id string) (*User, error) {
    user, err := db.Find(id)
    if err != nil {
        return nil, fmt.Errorf("failed to find user: %w", err)
    }
    return user, nil
}

// In main or init, panic is acceptable if the app MUST die
func main() {
    config, err := LoadConfig()
    if err != nil {
        panic("critical config missing: " + err.Error())
    }
}
```

**Benefits:**
- Improves application uptime and reliability
- Allows handlers to recover and return HTTP 500 instead of crashing the process
- Makes the code more predictable and testable

**Tools:** golangci-lint, staticcheck