Wenn ich nochmal auf diesen Artikel verweisen darf und das Problem dort mit Int32.Parse(). Das ist zwar C#-bezogen, aber die Problematik dort ist sprach-/frameworkunabhängig, nämlich: Exceptions sollten nicht für die Flusskontrolle verwendet werden. Solltest du auf so etwas stoßen, darfst du es als Designfehler abstempeln und die API-Designer darin kritisieren, dass es ein Boolean-Rückgabewert auch getan hätte und das viel eleganter.
...
Naja, ein Boolean-Rückgabewert geht da eben kaum, weil die Methode bereits ein Integer zurückgeben soll. Dass es keine einfache Möglichkeit gibt/gab (in Java ja bis heute genauso), vorher die Gültigkeit zu überprüfen (am besten auch noch, ohne dadurch die gleiche Arbeit zweimal zu erledigen, irgendwie will man ja doch noch Performance im Auge behalten) ist natürlich ungünstig, aber ich wüsste nicht wirklich, was die Methode bei einem ungültigen String machen sollte, außer eine Exception zu werfen. Und eine gute Möglichkeit, vorher die Gültigkeit zu testen, fällt mir auch spontan nicht ein, wenn man nicht für jedes Parsing ein eigenes Parser-Objekt erzeugen will.
(Disclaimer: All das bezieht sich auf Javas Integer.parseInt(), mit der implziten Annahme, dass das in C# praktisch genauso ausschauen wird.)
Zitat
@affe (wenn ich dich so nennen darf ^^):
Der klassische C-Ansatz ist doch eher, dass der Rückgabewert entweder in einem gültigen oder in einem ungültigen Wertebereich liegt, worauf man prüft, und der Fehlercode in einer globalen, "errno"-ähnlichen Variable gespeichert wird. Natürlich muss man immernoch den Fehlercode interpretieren, aber das kann man generalisiert erledigen.
...
Ja, meinte ich ja, halt irgendeinen speziellen Rückgabewert zurückliefern, ungeachtet dessen ob der jetzt direkt den konkreten Fehler angibt oder auch noch eine globale Variable (= inhärentes x__X) benötigt. Jedenfalls muss man jeden Aufruf in ein if hüllen – oder alle Rückgabewerte sammeln (bei nicht aufeinander aufbauenden Aufrufen) und dann eine Riesen-if-Party am Ende veranstalten. *kratz*
Und: Ja, darfst du. XD
Zitat von Kyuu
Also sowas wie
[…]
?
...
Habe ich auch schon gesehen, und in manchen komplizierteren Fällen ergibt's sogar Sinn. Als bloßen Workaround für GOTOs aber natürlich absolut grauslich. x__X
--
A human is a system for converting dust billions of years ago into dust billions of years from now via a roundabout process which involves checking email a lot.
Naja, ein Boolean-Rückgabewert geht da eben kaum, weil die Methode bereits ein Integer zurückgeben soll. Dass es keine einfache Möglichkeit gibt/gab (in Java ja bis heute genauso), vorher die Gültigkeit zu überprüfen (am besten auch noch, ohne dadurch die gleiche Arbeit zweimal zu erledigen, irgendwie will man ja doch noch Performance im Auge behalten) ist natürlich ungünstig, aber ich wüsste nicht wirklich, was die Methode bei einem ungültigen String machen sollte, außer eine Exception zu werfen. Und eine gute Möglichkeit, vorher die Gültigkeit zu testen, fällt mir auch spontan nicht ein, wenn man nicht für jedes Parsing ein eigenes Parser-Objekt erzeugen will.
(Disclaimer: All das bezieht sich auf Javas Integer.parseInt(), mit der implziten Annahme, dass das in C# praktisch genauso ausschauen wird.)
...
Man kann auch out-Parameter benutzen:
Und diese sind alles andere als unüblich.
Zitat von drunken monkey
Habe ich auch schon gesehen, und in manchen komplizierteren Fällen ergibt's sogar Sinn. Als bloßen Workaround für GOTOs aber natürlich absolut grauslich. x__X
...
Wenn man die Exception nicht fängt und nach außen propagieren lässt - und nur dann - wäre es sinnvoll, imo. Eleganter wäre es sowieso, wenn SomeFunc() selbst wirft, aber selbstverständlich kann es sein, dass diese zu irgendeiner externen Bibliothek gehört, die aus irgendeinem Grund keine Exceptions nach außen lässt, oder sie überhaupt nicht verwendet.
Ah, OK, deswegen eben mein Disclaimer. In Java gibt's die ja nicht.
In C# wäre das dann wohl wirklich die deutlich bessere Lösung.
--
A human is a system for converting dust billions of years ago into dust billions of years from now via a roundabout process which involves checking email a lot.