Also bin ich auf diese (IMHO) sehr nette Idee gestoßen, eine zusammengesetzte Struktur aus einem Rückgabewert und einer Ausnahme zu verwenden -Expected<T>. Es überwindet viele Mängel der herkömmlichen Methoden zur Fehlerbehandlung (Ausnahmen, Fehlercodes).

Siehe dieAndrei Alexandrescus Vortrag (Systematische Fehlerbehandlung in C ++) undseine Folien.

Die Ausnahmen und Fehlercodes haben grundsätzlich dieselben Verwendungsszenarien mit Funktionen, die etwas zurückgeben, und mit Funktionen, die dies nicht tun.Expected<T>Auf der anderen Seite scheint es sich nur um Funktionen zu handeln, die Werte zurückgeben.

Meine Fragen lauten also:

Hat jemand von euch es versucht?Expected<T> in der Praxis?Wie würden Sie diese Redewendung auf Funktionen anwenden, die nichts zurückgeben (dh leere Funktionen)?

Aktualisieren:

Ich denke, ich sollte meine Frage klären. DasExpected<void> Spezialisierung macht Sinn, aber ich bin mehr daran interessiert, wie es verwendet wird - die konsequente Umgangssprache. Die Implementierung selbst ist zweitrangig (und einfach).

Zum Beispiel gibt Alexandrescu dieses Beispiel (ein bisschen bearbeitet):

string s = readline();
auto x = parseInt(s).get(); // throw on error
auto y = parseInt(s); // won’t throw
if (!y.valid()) {
    // ...
}

Dieser Code ist so "sauber", dass er auf natürliche Weise fließt. Wir brauchen den Wert - wir bekommen ihn. Mitexpected<void> man müsste die zurückgegebene Variable erfassen und eine Operation ausführen (wie.throwIfError() oder so), was nicht so elegant ist. Und natürlich.get() macht mit void keinen sinn.

Also, wie würde Ihr Code aussehen, wenn Sie eine andere Funktion hätten, sagen wirtoUpper(s), der die Zeichenfolge direkt ändert und keinen Rückgabewert hat?