---
id: 448c02f1efb1042bc9e1d256fcd2acad
author: Rabbit Princess
title: Warum Go explizite Fehlerrückgabe und panic-recover anstelle des Auslösens von try-catch-Ausnahmen wählt
description: Es werden die Grenzen von try-catch-Strukturen untersucht, die die Verantwortung für die Behandlung von Ausnahmen entlang des Aufrufstapels weitergeben, und das Designkonzept von Gos panic-recover erläutert, das sich auf explizite Fehlerbehandlung an der Aufrufstelle und auf nicht behebbare Zustände beschränkt.
language: de
date: 2024-10-16T07:06:25.186989697Z
path: /blog/posts/why-doesn-t-go-have-try-catch-zeb312147
category: language
lang_canonical:
    ko: https://blog.naver.com/sjc02183/222927597790
---

Go unterstützt bewusst kein try-catch, sondern nur die Sprachkonstrukte panic und recover. Dies hat bei vielen Entwicklern, die an die Fehlerbehandlung mit try-catch gewöhnt sind, Unmut ausgelöst. Warum also verzichtet Go auf try-catch? Der Grund ist, dass try-catch mehrere Probleme mit sich bringt.

## try-catch-finally

Das Konstrukt try-catch (Try-Catch) dient der Behandlung von Fehlerfällen und Ausnahmesituationen, die während der Ausführung eines Programms (zur Laufzeit) auftreten können. Der finally-Block enthält Code, der unabhängig davon, ob eine Ausnahme aufgetreten ist, auf jeden Fall ausgeführt werden muss.

## Fehlerbehandlung und Verantwortung

In den 1980er und 1990er Jahren war die Fehlerbehandlung sehr einfach. Die Fehlermeldungen beschränkten sich auf „Diskette voll", „Kein Diskettenlaufwerk vorhanden" und „Keine Schreibberechtigung für die Diskette", und Entwickler dieser Zeit warfen Fehler im Falle eines Auftretens bis zur zentralen Fehlerbehandlungsstelle weiter (throw) und vereinheitlichten so die Behandlung. In dieser Situation funktionierte das try-catch-Konstrukt effizient.

Mit der Zeit änderte sich die Lage jedoch. Die Geschäftslogik wurde komplexer, es kamen Datenbanken und Transaktionen hinzu, durch den Aufruf zahlreicher APIs über das Netzwerk mussten unzählige Request-Nachrichten interpretiert werden, und mit dem Aufkommen der nebenläufigen Programmierung musste man Fehler sogar in anderen Threads als dem Hauptthread behandeln.

Fehler ließen sich nicht mehr an einer einzigen Stelle behandeln, und keine einzelne Stelle konnte mehr die Verantwortung für alle Fehler übernehmen. Hier entsteht ein gravierendes Problem bei try-catch.

## Die Verantwortungsabwälzung bei try-catch

try-catch ist, kurz gesagt, eine Methode, mit der die Stelle, an der ein Fehler auftritt, die Verantwortung für die Fehlerfolgen (die Nachbearbeitung) an jemand anderen weitergibt. Dieser Empfänger kann der catch-Block sein, die aufrufende Methode, die aufrufende Methode der aufrufenden Methode der aufrufenden Methode der aufrufenden Methode … oder irgendjemand anderes. Mit anderen Worten: In einer Welt, in der die Fehlerbehandlung immer umfangreicher und komplexer wird, besteht die Lösung von try-catch darin, zu hoffen, dass „irgendjemand es schon erledigen wird“. Betrachten wir den folgenden Code.

```java
try {
    data = readFile("hello.txt");
    structuredData = parseData(data);
    insertDBStatus(structuredData[1]);
    startHTTPServer(structuredData[2]);
} catch (Exception e) {
    e.printStackTrace();
}
```

Das Problem des obigen Codes besteht darin, dass unklar bleibt, wer für die Verarbeitung von printStackTrace zuständig ist, und man auch nicht erkennen kann, in welchem Code der Fehler aufgetreten ist. Je mehr Logik im try-Block steht, desto schlimmer wird das Problem. Paradoxerweise wurden Entwickler jedoch umso abhängiger vom try-catch-Konstrukt, das die Verantwortung abwälzt, je komplexer die Entwicklung wurde. Sie machten sich keine Gedanken mehr über die Fehlerbehandlung, ihr Verantwortungsbewusstsein ließ nach und letztlich vergaßen sie das Wesen der Fehler- und Ausnahmebehandlung. Wie hat Golang dieses Problem gelöst?

## panic, recover

Einer der Vorzüge von Go ist, dass es verschiedene Systeme gibt, die Entwickler nicht auf einen falschen Weg führen, sondern sie zu guten Entwicklern machen sollen. Auch panic und recover sind ein Beispiel dafür.

Panic und recover unterscheiden sich auf den ersten Blick kaum von try-catch, doch sie unterscheiden sich darin, dass die Verantwortung bei einem Problem nicht nach außen abgegeben wird. Tritt in Go eine Panik auf, muss der Wert nicht nach außen gegeben werden, sondern die Behandlung muss an der Stelle erfolgen, an der die Panik ausgelöst wurde. Dies verleiht dem Entwickler die Verantwortung für die Fehlerbehandlung und veranlasst ihn, gründlicher darüber nachzudenken, wo, durch wen und wie der jeweilige Fehler behandelt werden sollte. Es ist gewissermaßen so, dass dem Anwender Selbstbestimmung gewährleistet wird und zugleich Raum zum Nachdenken bleibt.

Auch die Wahl des Begriffs panic ist sehr treffend. Anders als bei try-recover erzeugt das Wortpaar panic-recover allein durch seine Bedeutung den Druck, dass es nur bei eindeutigen Fehlersituationen und nicht bei bloßen Ausnahmesituationen verwendet werden sollte. Entwickler verwenden recover daher ganz natürlich nicht im Übermaß, sondern nur dort, wo es notwendig ist. Dies trägt in Go wesentlich dazu bei, prägnanten Code zu schreiben.