Rückgabewert

[Finnegan]

Edit: Ups! Habe gerade erst gesehen, dass @wob eine Variante von expected<T> bereits erwähnt hat. Nix für ungut, ich lass meine Gedanken dazu dennoch mal hier stehen:

Ich würde bei dieser Diskussion einfach nochmal gerne Alexandrescu's expected<T> in den Raum werfen. Ein Typ ähnlich wie std::optional<T>, der entweder den erwarteten Wert enthält, oder einen Fehler, der beschreibt, warum der erwartete Wert nicht vorhanden ist (z.B. als gekapselte, jedoch noch nicht geworfene Exception).

Eine Exception wird von expected<T> erst bei dem Versuch geworfen, auf einen nicht vorhandenen Wert zuzugreifen. Alternativ kann man den Fehler auch wie einen zurückgegebenen Errorcode behandeln.

Die Flexibilität eines solchen hybriden Ansatzes hat es mir irgendwie schon angetan, da man oft nicht vorher wissen kann, ob ein Fehler in dem Kontext, in dem man die Funktion verwendet, wirklich eine "Ausnahme" oder vielleicht doch eher die Regel ist.

Nehmen wir mal std::stoi als Beispiel. Diese Funktion wirft im Fehlerfall eine Exception. Wenn ich diese Funktion z.B. beim Parsen einer Konfigurationsdatei verwende, kann man durchaus argumentieren, dass es sich dabei um eine "Ausnahme" handelt. Der Regelfall ist eine syntaktisch korrekte Config, mit der das Programm starten kann.

Verwende ich die Funktion hingegen in einem Programm, das z.B. wilde, unstrukturierte Daten-Dumps analysiert, kann ein std::stoi-Fehler in diesem Kontext durchaus etwas völlig Erwartetes sein, das sehr häufig auftritt. In diesem Fall wären die Exceptions keine gute Wahl und wirken sich sogar negativ auf die Laufzeit aus - tatsächlich geworfene Exceptions sind ja nicht gerade kostenlos.

Ansätze wie expected<T> haben das Potenzial in beiden Situationen zu glänzen: Ich bin nicht gezwungen, die Errorcodes zu behandeln oder weiterzureichen und kann mich da auf den Exception-Mechanismus verlassen, aber ich kann es tun - z.B. aus Performancegründen oder weil der Fehler in meinem aktuellen Kontext gut lokal behandelbar ist.