nicht angemeldet
Rolf bDito @ dedlfichs, das sehe ich auch als eine der besseren Ideen von Java und würde mich in C# oder PHP drüber freuen.
1unitedpower, komm mir nicht mit den Vorteilen von statischen Typchecks, oder ich gebe Dir augenblicklich recht. Die Union Types sind vielleicht auch Geschmacks- oder Gewöhnungssache. Ich kenne sie nicht und tue mich vielleicht deshalb schwer damit.
Die Beispiele mit mixed-Ergebnissen sind alle darauf ausgelegt, das Ergebnis von Fehlerabfragen in der Funktion nach außen zu reichen. Die Frage ist nur, was der Aufrufer dann damit macht. Im Falle unserer Division durch 0 liegt ein Algorithmusfehler vor. Im Falle von z.B. mysqli::query bedeutet FALSE "Failure", ohne dass die Doku spezifziert, was damit gemeint ist. Es könnte eine abgebrochene DB-Verbindung sein, ein SQL Syntaxfehler, oder wer weiß was. Würde eine SqlException oder eine NetworkException geworfen, könnte ich das das entsprechend catchen und behandeln. Und im NORMALFALL kommen diese Situationen nicht vor, warum soll ich also den Code für meine DB-Abfrage durch ständiges Abfragen von Fehlerergebnissen bloaten. Out-of-line im Catch-Block sind sie viel besser aufgehoben.
Anders ist es, wenn ein Fehler "normal" sein kann, z.B. ein nicht gefundener Treffer in einer Suche. Dafür ist eine Exception falsch und es ist Tradition, spezielle Ergebniswerte zurückzugeben. Das ist sicher nicht der Weisheit letzter Schluss und ein Union Type könnte es besser handhabbar machen. Man kann es nur nicht durchgängig einführen, oder müsste alle APIs, die Sonderwerte nutzen, deprecaten und Alternativ-APIs mit Union Type API einführen. Möglicherweise hat man den Aufwand gescheut, die Union Types nach Einführung als Sprachelement dann auch in die Breite zu bringen.
Ich möchte mich jetzt aus der Diskussion zurückziehen, es kostet mich zu viel Zeit und ich glaube auch nicht, dass wir auf einen Nenner kommen. Unsere Meinungen haben wir dargelegt :)
Gruß
Rolf
MudGuard
Matthias Apsel