Error Codes

Kurz: Numerische oder textuelle Kennungen, die eine Fehlerart identifizieren — z. B. der Exit-Code eines Java-Programms (System.exit(1)) oder eigene Fehlercodes in einer Exception.

Genauer: Java selbst arbeitet primär mit typisierten Exceptions statt reinen Fehlercodes wie in C — eine eigene Exception-Klasse mit einem Feld für einen Fehlercode kombiniert aber oft beide Ansätze, wenn z. B. eine externe API mit numerischen Codes angebunden wird.

Im Detail

// Eigene Exception mit angehängtem Fehlercode für eine externe API-Anbindung
class ApiException extends RuntimeException {
    private final int fehlercode;
 
    public ApiException(String nachricht, int fehlercode) {
        super(nachricht);
        this.fehlercode = fehlercode;
    }
 
    public int getFehlercode() {
        return fehlercode;
    }
}
 
try {
    // ... API-Aufruf, der mit HTTP-Statuscode 404 fehlschlägt
    throw new ApiException("Ressource nicht gefunden", 404);
} catch (ApiException e) {
    if (e.getFehlercode() == 404) {
        System.out.println("Nicht gefunden - Standardwert verwenden");
    } else {
        throw e; // unbekannter Code - weiterreichen statt schlucken
    }
}
 
System.exit(1); // Prozess-Exit-Code 1 signalisiert dem aufrufenden Shell-Skript einen Fehler

Der Prozess-Exit-Code (0 bis 255, 0 bedeutet konventionell “erfolgreich”) ist besonders relevant bei Kommandozeilen-Tools oder Skripten, die in eine größere Pipeline eingebettet sind — ein aufrufendes Shell-Skript oder eine CI-Pipeline prüft diesen Code, um zu entscheiden, ob der nächste Schritt laufen soll. System.exit() sollte man dabei sparsam einsetzen: es beendet die JVM sofort und unterläuft dabei ggf. finally-Blöcke und ordentliches Ressourcen-Aufräumen — in normalen Anwendungsklassen gehört ein Fehler fast immer als geworfene Exception behandelt, System.exit() bleibt dem allerobersten Einstiegspunkt (main) vorbehalten.

Fehlercodes vs. Exception-Hierarchien

Sprachen wie C oder Go setzen traditionell stärker auf Fehlercodes als Rückgabewerte statt auf Exceptions — der Aufrufer muss den Rückgabewert JEDES Aufrufs manuell prüfen, sonst wird ein Fehler stillschweigend ignoriert. Javas Exception-Mechanismus dreht das um: Eine ungefangene Exception propagiert automatisch nach oben und beendet im schlimmsten Fall das Programm mit einem Stacktrace, statt einfach übersehen zu werden. Der Nachteil von Exceptions ist der etwas höhere Laufzeitaufwand beim tatsächlichen Werfen (Stacktrace-Erstellung) — in performancekritischem Code, der sehr häufig erwartbare “Fehler” behandelt (z. B. beim Parsen großer Datenmengen mit teils ungültigen Zeilen), wird deshalb manchmal bewusst auf ein Rückgabewert-Muster mit optionalen Werten (Optional<T>) statt Exceptions zurückgegriffen.

HTTP-Statuscodes als bekanntestes Beispiel

Das oben gezeigte Muster (Exception mit angehängtem numerischen Code) begegnet einem in der Praxis am häufigsten bei HTTP-Clients: 4xx-Codes (Client-Fehler, z. B. 404 Nicht gefunden, 401 Nicht autorisiert) und 5xx-Codes (Server-Fehler, z. B. 500 Interner Serverfehler) werden oft in eine typisierte Exception-Hierarchie übersetzt, damit aufrufender Code gezielt auf bestimmte Fehlerarten reagieren kann, ohne den rohen Zahlencode jedes Mal selbst interpretieren zu müssen.

Siehe auch: Exceptions, Errors