Immer wieder lese oder höre ich, dass Go-Anfängern dieses ständige

if err != nil

nicht gefällt. Selbst auf dem sehr lustigen Vergleich If programming languages were weapons kam dieser Punkt auf:

Ich bin da eher der Meinung, dass man falsch an die ganze Sache ran geht, wenn man das so sieht. Fangen wir doch mal an, mit anderen Lösungsansätzen zu vergleichen.

try-catch-Blöcke

Seit es PHP5 gibt, sind try-catch-Blöcke in PHP möglich und erfreuen sich großer Beliebtheit. In Java gibt es das natürlich schon länger und selbst Python hat Exceptions.
Leider gibt es grad in der Scriptsprachen-Welt sehr viele Hohlbirnen, die der Meinung sind, es sei total knuffig, einfach um alles in der main()-Methode ein try mit entsprechend generischem Catcher zu setzen.
Einfach alles abzufangen und in den eigentlichen aufrufenden Methoden immer davon auszugehen, dass sich schon der äußere Catch drum kümmern wird, dass zumindest eine Fehlermeldung ausgegeben wird, kann man schon so machen, ist aber leider sehr kurz gedacht und führt z.B. bei Web-Applikationen dazu, dass man nicht eine spezifische Meldung sieht, was grad gegen die Wand gefahren ist, sondern ein Error 500 oder ein “An error occurred” - das führt dann gerne dazu, dass Menschen Bescheid sagen, dass die Webseite nicht funktioniert.

$ok-Variablen

Es geht natürlich noch besser. Ganz ohne spezielle Fehlerbehandlung. Man schleift einfach durch die gesamte Software ein $ok (mit oder ohne Dollarzeichen hängt jetzt einfach mal von der Sprache ab). Sobald ein Fehler auftritt, setzt man diese dann auf false und schon weiss der Rest des Programms, dass er so nicht weiterarbeiten darf. Warum genau nicht und was vielleicht noch zu tun ist (DB-Connection schließen, Schreibvorgänge finalisieren), hat dann den Rest auch nicht zu interessieren.

if err != nil

Ich muss gestehen: Als ich mit Go anfing, fand ich das ziemlich komisch. Die Methoden hatten multiple Rückgabewerte und oft war der zweite vom Typ error.
Go beschwert sich selbstverständlich auch, wenn man multiple Rückgaben hat, aber nur eine Variable zuweist.

Nehmen wir also folgende Beispielmethode:

func Foo() (string, error) {
	return "bar", errors.New("My Error")
}

Was also nicht geht:

func main() {
	bla := Foo()
}

Es muss lauten:

func main() {
	baz, err := Foo()
	if err != nil {
		// Error Handling
	}
	fmt.Print(baz)
}

Oder man entscheidet sich wirklich explizit dafür, den zurückgegebenen Error zu ignorieren:

func main() {
	baz, _ := Foo()
	fmt.Print(baz)
}

Aber genau das ist der Punkt: Man muss sich explizit dafür entscheiden, genau diesen Fehler zu ignorieren oder ihn eben weiter zu verarbeiten, zurückzugeben oder was auch immer. Das zwingt den Entwickler dazu, sich aktiv damit auseinanderzusetzen, was als nächstes passiert oder was passieren könnte.

Ich mag das.