Reserve `panic` for unrecoverable situations (like invariant violations or truly fatal errors). For expected error conditions (file not found, invalid input, etc.), return an `error` to the caller instead of panicking.
Using panic for normal errors will crash the program and skip normal error handling logic. It makes the code less robust and harder to reuse. By returning errors, you allow the caller to decide how to handle the failure, leading to more graceful degradation and better reliability.
Side-by-side examples engineers can pattern-match during review.
func GetConfig(path string) []byte {
data, err := os.ReadFile(path)
if err != nil {
panic("could not read config: " + err.Error())
}
return data
}func GetConfig(path string) ([]byte, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("could not read config: %w", err)
}
return data, nil
}func GetConfig(path string) []byte {
data, err := os.ReadFile(path)
if err != nil {
panic("could not read config: " + err.Error())
}
return data
}func GetConfig(path string) ([]byte, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("could not read config: %w", err)
}
return data, nil
}From the same buckets as this rule.
Check if loops use equality operators (== or !=) in termination conditions. These can lead to infinite loops if the condition is never met exactly. Instead, use relational operators like < or > for safer loop termination.