Warum hat Go kein Try-Catch?

Go unterstützt absichtlich keine try-catch-Anweisung, sondern nur die panic-recover-Syntax. Dies hat bei vielen Entwicklern, die mit der Fehlerbehandlung mittels try-catch vertraut sind, zu Unmut geführt. Was ist also der Grund dafür, dass try-catch nicht implementiert wird? Der Grund dafür ist, dass try-catch mehrere Probleme mit sich bringt.

try-catch-finally

Die try-catch-Anweisung ist eine Anweisung zur Behandlung von Fehlern und Ausnahmesituationen, die während der Programmausführung (Laufzeit) auftreten können. Die finally-Anweisung enthält Code, der unabhängig davon, ob eine Ausnahme aufgetreten ist oder nicht, unbedingt ausgeführt werden muss.

Fehlerbehandlung und Verantwortung

In den 80er und 90er Jahren war die Fehlerbehandlung sehr einfach. Fehlermeldungen beschränkten sich auf „Diskette voll“, „Keine Diskette im Laufwerk“ und „Keine Schreibberechtigung für die Diskette“. Entwickler dieser Zeit warfen den Fehler bis zur Fehlerbehandlungsstelle, um ihn gemeinsam zu behandeln, wenn ein Fehler auftrat. In dieser Situation funktionierte die try-catch-Anweisung effizient.

Im Laufe der Zeit hat sich die Situation jedoch geändert. Die Geschäftslogik wurde komplexer, es kamen Datenbanken und Transaktionen hinzu, und durch den Aufruf zahlreicher APIs über das Netzwerk mussten viele Request-Nachrichten interpretiert werden. Darüber hinaus musste mit dem Aufkommen der gleichzeitigen Programmierung ein Fehler in einem anderen Thread als dem Hauptthread behandelt werden.

Fehler wurden so komplex, dass sie nicht mehr an einer Stelle behandelt werden konnten, und niemand konnte mehr die Verantwortung für alle Fehler übernehmen. Hier tritt ein ernstes Problem mit try-catch auf.

Verantwortungsübertragung durch try-catch

Try-catch ist, mit anderen Worten, eine Methode, bei der die Person, die den Fehler verursacht hat, die Verantwortung (die Nachbearbeitung) für das Auftreten des Fehlers an jemand anderen delegiert. Das Ziel dieser Delegation kann die catch-Anweisung, die eigene übergeordnete Methode oder die übergeordnete Methode der übergeordneten Methode der übergeordneten Methode usw. sein. Mit anderen Worten, in einer Welt, in der die Fehlerbehandlung immer umfangreicher und komplexer wird, hat try-catch die Methode gewählt: "Irgendjemand wird es schon tun". Betrachten wir den folgenden Code.

1try {
2    data = readFile("hello.txt");
3    structuredData = parseData(data);
4    insertDBStatus(structuredData[1]);
5    startHTTPServer(structuredData[2]);
6} catch (Exception e) {
7    e.printStackTrace();
8}

Das Problem mit dem obigen Code ist, dass es unklar ist, wer für die Behandlung von printStackTrace verantwortlich ist und in welchem Code ein Fehler aufgetreten ist. Wenn sogar noch mehr Logik in der try-Anweisung vorhanden ist, wird das Problem noch schlimmer. Paradoxerweise wurden Entwickler jedoch, je komplexer die Entwicklung wurde, süchtig nach der try-catch-Anweisung, die Verantwortung überträgt, und hörten auf, über die Fehlerbehandlung nachzudenken. Das Verantwortungsbewusstsein schwand, und schließlich vergaßen sie das Wesen der Fehler- und Ausnahmebehandlung. Wie hat Go dieses Problem gelöst?

panic, recover

Einer der Vorteile von Go ist, dass es mehrere Systeme gibt, die Entwickler zu guten Entwicklern machen, anstatt sie auf den falschen Weg zu führen. Panic-recover ist ein weiteres Beispiel dafür.

Panic und Recover scheinen auf den ersten Blick keine Unterschiede zu try-catch zu haben, aber der Unterschied besteht darin, dass die Verantwortung bei einem Problem nicht an Dritte delegiert wird. Wenn in Go ein Panic auftritt, sollte der Wert nicht an Dritte weitergeleitet werden, sondern an der Stelle gelöst werden, an der der Panic aufgetreten ist. Dies gibt dem Entwickler die Verantwortung für die Fehlerbehandlung und fordert ihn auf, intensiver darüber nachzudenken, wo, wer und wie der Fehler zu behandeln ist. Es garantiert dem Benutzer Autonomie, lässt aber gleichzeitig Raum zum Nachdenken.

Auch die Wahl des Wortes "panic" ist sehr bemerkenswert, denn im Gegensatz zu try-recover übt panic-recover allein schon durch das Wort Druck auf den Entwickler aus, es nur in eindeutigen Fehlersituationen und nicht in Ausnahmesituationen zu verwenden. Dadurch wird der Entwickler automatisch dazu gebracht, recover nicht zu missbrauchen und es nur bei Bedarf zu verwenden. Dies trägt wesentlich zu einem prägnanten Code in Go bei.