Ein `panic()`-Aufruf in einem Go-Package außer main. Er wickelt die Goroutine des Aufrufers ab, statt einen Fehler zurückzugeben, den der Aufrufer behandeln könnte.
Jedes Beispiel zeigt genau die Codeform, nach der die Regel sucht, und dann die kleinste Version, die die Absicht bewahrt, ohne Risiken zu verstecken oder Rauschen hinzuzufügen.
package config
func Load(path string) Config {
data, err := os.ReadFile(path)
if err != nil {
panic(err)
}
return parse(data)
}Deterministischer Zeilenabgleich: beanstandet `panic(` in `.go`-Dateien außerhalb von Tests, deren Package nicht `main` ist.
package config
func Load(path string) (Config, error) {
data, err := os.ReadFile(path)
if err != nil {
return Config{}, fmt.Errorf("read config %s: %w", path, err)
}
return parse(data), nil
}Gib einen Fehler zurück (`fmt.Errorf("...: %w", err)`) und lass den Aufrufer entscheiden. Reserviere `panic` für wirklich unmögliche Zustände und kennzeichne diese mit einem Kommentar.
Agenten behandeln `panic` wie `throw` aus anderen Sprachen und nutzen es für gewöhnliche Fehler. In Go sind Fehler in Libraries Werte, über die der Aufrufer entscheidet.
ai-slop/go-library-panic
ai-slop
Deterministischer Zeilenabgleich: beanstandet `panic(` in `.go`-Dateien außerhalb von Tests, deren Package nicht `main` ist.
`package main`, `_test.go`-Dateien, Packages, deren Name auf `test` endet, Testhilfe-Pfade wie `testdata/` und `testutil/`, Panics mit einem Kommentar in den drei Zeilen darüber sowie kurze String-Panics direkt unter einem `if x == nil`-Guard werden nicht beanstandet.
Erschienen in aislop v0.8.0 mit den Go-Detektoren; dasselbe Release nahm nach einer Validierung an Open-Source-Projekten Nil-Check-Vorbedingungen aus.