Vor kurzem war ich wieder an einem Punkt, an dem ich aufgrund fehlender Erfahrung nicht weiterwusste und musste mir Meinungen einholen. Das Thema war Fehlerbehandlung, oder genauer Exceptions. Wie man Exceptions auslöst, einfängt, etc. weiß jeder, das ist Syntaxkram und Referenzmaterial dazu findet man an jeder Ecke. Was mir teilweise Kopfzerbrechen bereitet hat, war, dass ich realisierte nicht wirklich zu wissen wie man Exceptions sinngemäß einsetzt. Nach stundenlangen Recherchen im Internet war ich zwar um eine Vielzahl an Meinungen, was Exceptions sind, wozu sie gedacht sind und wie man sie am besten einsetzt, schlauer, aber so richtig sinnvoll empfand ich keine davon. Schließlich bin ich über diesen Artikel gestolpert, in dem noch die letzten, für mich noch fehlenden Aspekte deutlich hervorgehoben waren.
Wie ist es eigentlich bei euch? Bevorzugt ihr Fehlercodes? Exceptions? Assertions? Mit welcher Begründung? Und falls ihr euch nicht vor Exceptions scheut, wie sieht eure Strategie dazu aus?
Kann ich schwer sagen. Ich war mal sehr prozedural und kannte daher gar keine Exceptions (die sind doch OOP-only, oder?). Inzwischen benutze ich hauptsächlich Java (Studium) und bin daher zumindest mit den von Java selbst geworfenen Exceptions konfrontiert, die ich meistens aber gar nicht fange, weil ich auch nur irgendwelche Methoden implementiere, die dann mit falschem Input gefüttert wurden und die Exception daher ruhig den Caller erreichen soll - ich könnte sie höchstens noch in eine eigene Exception wrappen, aber was bringt das?
Ich finde das Konzept von Exceptions eigentlich sehr sinnvoll, auch wenn ich sie wenig nutze. Insbesondere bei Rekursion können sie Fehlerbehandlung sehr vereinfachen und in ihnen lassen sich gleich detailliertere Informationen über die Art des Fehlers speichern - die "C-Approach", nur nen Fehlercode zurückzuliefern unter dem sich der Programmierer/der Benutzer dann was vorstellen soll, finde ich da ziemlich braindead. In ner Exception kann ich dann auch gleich schreiben, welche Datei nicht geöffnet werden konnte, in welcher Rekursionstiefe das Problem aufgetreten ist, und diese Informationen an der relevanten Stelle wieder auswerten, ohne sie erstmal dahin transportieren zu müssen.
Zitat
Bevorzugt ihr Fehlercodes? Exceptions? Assertions?
...
Sind Assertions nicht auch nur Exceptions, die unter bestimmten Umständen fliegen?
Zitat
Und falls ihr euch nicht vor Exceptions scheut, wie sieht eure Strategie dazu aus?
...
Ich würde sagen, intern auch für trivialere Dinge verwenden, wenns die einfachste Implementierung ist, nach außen nur kommen lassen, wenn der Aufrufende Schuld ist. Wenns ein UI gibt, und der User Schuld ist, natürlich schon fangen, aber dem User präsentieren und so...
Assertions sind abschaltbare Exceptions, die in der Regel dazu gedacht sind, Programmierfehler zu finden, keine Anwenderfehler. Bei der normalen Benutzung werden sie in der Regel deaktiviert.
Exceptions sind eindeutig eine der besseren Erfindungen, und imo auch eine die notwendig war. Der C-Approach ist ja wirklich bescheuert – wenn guter Stil so aussieht, dass man jeden einzelnen Funktionsaufruf in ein if wrapped, kann irgendwas mit der Sprache nicht ganz stimmen. o_O" Exceptions sorgen da gleich für viel mehr Ordnung und erleichtern auch vieles ungemein.
Strikte Regeln, wann man Exceptions einsetzen soll, würde ich mir keine machen – einfach einsetzen, wenn sie den Code lesbarer, klarer oder sonstwie "besser" machen, das sollte man mit etwas Erfahrung dann schon einschätzen können. Natürlich nicht komplett zweckentfremden und z.B., wie manche es schon gemacht haben, als Ersatz für Rückgabewerte nehmen. o_O" Aber wenn etwas in einer Methode schief gehen kann, sollte sie dann imo auch eine entsprechende Exception werfen. Zumindest, wenn das die Methode nicht selber ausbügeln kann.
Und @ Orcey: Naja, Exceptions sind nicht wirklich OOP-spezifisch, auch wenn sie großteils wohl echt in OOP-Sprachen vorkommen. Aber in PHP z.B. gibt's auch welche – Objekte zwar auch, aber man bekommt auch Exceptions ohne je ein anderes Objekt angefasst zu haben. Für ein echtes Beispiel müsste ich allerdings scharf nachdenken – oder natürlich bei Wikipedia cheaten. XD Ah, Prolog hätte mir sogar einfallen können…*kratz*
Und weird, ich dachte PHP hätte schon vor v5 was Exception-mäßiges gehabt…o_O"
--
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.
Ich sehe schon, ich hatte eher die C-Assertions im Sinn, als die Assertions aus Java, die sich offenbar darin unterscheiden, dass in C eine fehlgeschlagene Assertion zum sofortigen Abbruch des Programms mit einer entsprechenden Fehlermeldung in der Ausgabe führt, während Java eine Exception wirft. Im Endeffekt ist die Definition der Assertion in beiden Fällen aber natürlich identisch, denn es geht dabei um Bugs im Programmcode und nicht um die Behandlung von fehlerhaftem Userinput.
Jedenfalls habe ich auch schon Leute gesehen, die grundsätzlich Assertions (C/C++) den Exceptions vorziehen, nicht zuletzt aus performancetechnischen Gründen, die natürlich unter Umständen auch gerechtfertigt sein können, aber nicht grundsätzlich und meiner Meinung nach auch nicht in der Regel.
Was ich mit "Strategie" im Sinn hatte, war eher in Richtung wie eure Exceptionhierarchie aussieht, falls eine vorhanden. Ob ihr benutzerdefinierte Exceptions verwendet, diese rigoros von der Basis-Exceptionklasse, je nach Härte von der entsprechenden, vom Framework zur Verfügung gestellten Exceptionklasse (C++: runtime_error vs. logic_error), oder überhaupt nicht ableitet. Wie ihr eure Ausnahmefälle strukturiert, usw.
Wie bereits geschrieben, habe ich schon einiges an Meinungen zu Exceptions gelesen und natürlich gibt es bei all den Unterschieden in der Auffassung und im Einsatz auch Konstanten, über die ein mehr oder weniger allgemeiner Konsens herrscht.
So sollten Exceptions nicht für den Control Flow verwendet werden, nur tatsächliche Ausnahmefälle markieren (die Definition, was ein Ausnahmefall ist, schwankt natürlich), in diesem Zusammenhang auch: nicht für jeden möglichen Ausnahmefall eine eigene Exceptionklasse erstellen, sondern generalisieren und die Details in die Fehlermeldungen verlagern, selbstverständlich immer eine Basis-Exceptionklasse haben, damit die Ausnahmebehandlungsblöcke nicht "explodieren", etc.
Irgendwo habe mal Folgendes gelesen, was ich hoffentlich richtig wiedergebe, da ich den entsprechenden Kommentar nicht mehr finde und es doch schon eine Weile her ist:
Exceptions sollten immer dann geworfen werden, wenn eine fundamentale Annahme verletzt wurde.
Beispiel: Eine Funktion erhält als Parameter ein Objekt der Klasse List und soll "true" zurückgeben falls die Liste mehr Elemente enthält als 50, anderenfalls "false". Die Annahme, die hier gemacht wird, ist dass der Parameter ein Objekt der Klasse List ist. Übergebe ich nun aber einen Nullzeiger, ist diese Annahme verletzt und die Funktion befindet sich in einem Zustand, aus dem sie nicht mit den definierten Regeln zum Aufrufer zurückkehren kann. Die Funktion muss eine Exception werfen.
Was die Frage angeht, ob Exceptions strikterweise zur OOP gehören, so denke ich auch, dass es nicht notwendigerweise der Fall sein muss. Exceptions werden in der Regel in objektorientierten Programmiersprachen geworfen, allerdings hindert nichts daran PODs oder Basistypen zu werfen, wie C++ es eindrucksvoll demonstriert: Java-Leute würden sich davor sträuben, was man dort alles werfen kann.
Naja, jedenfalls sind Exceptions eine relativ komplizierte Sache, wenn man tiefer eintaucht und ihren Sinn verstehen und sie sinngemäß einzusetzen wissen will, meinen eigenen Beobachtungen (die mich einschließen) jedenfalls zur Folge. Einige sind ja immernoch der Meinung Exceptions werden heute noch missverstanden und das sogar auf dem Level von Frameworks wie .NET oder Java. Darüber, dass viele Programmierer nichtmal wissen, was Exceptions sind, geschweige denn, wie man sie richtig einsetzt und sie nicht zuletzt aus diesem Grund meiden, herrscht sowieso ein allgemeiner Konsens, denn dass Exceptions ein mächtiges Werkzeug sind, ist nicht abzustreiten.
In C++ sind Exceptions sowieso ein Fall für sich und es werden dem Entwickler viele Steine in den Weg gelegt, so etwa bei dynamischen Bibliotheken plus Exceptions, so dass ich durchaus den ein oder anderen verstehen kann, wenn er sie ablehnt.
Uh Exceptions... Leider kann ich nur von Java berichten und was ich da gelernt habe ließ mich genau auf die Fragen stoße die du die gestellt hast: "Welchen Sinn machen sie?" In Java sind ja so gut wie alle Exceptions bereits vorhanden und eigene lohne sich imho nur für das hochpropagieren oder bei den erwähnten komplexen Rekursionen.
Ansonsten finde ich, das es den Code unnötig auf bläht.
Ich weiß nicht wie es in C++ ist, aber in Java gibt es ja sowieso checked und uncheked Exceptions, also solche die gefangen werden müssen und solche die nicht gefangen werden müssen. So wird man in IDE's soweiso sofort darauf aufmerksam gemacht das man hier einen Try-Block benötigt oder aber die Exception propagiert.
In Java ganz eindeutig. Aber in Java geht es ohnehin darum, ein gegebenes Problem unter Einsatz möglichst vieler Klassen zu lösen und wenn man nicht jeden zweiten Funktionsaufruf in try/catch wickelt, gilt das als schlechter Stil (so viel übrigens zu C++s häßlichen ifs).
In C++ hab' ich die Dinger nie angefaßt. Aber Ich verwende eh 90% von C++s Fähigkeiten nicht, weil sie arkan, mir nicht bekannt oder auf den ersten Blick komplizierter als eine äquivalente Selbstimplementierung sind.
In PHP benutze ich auch keine. Da jede Funktion alles zurückgeben kann und man mit Assertions oft gerade mal ein Bit an Information liefert (namentlich, daß die aufgerufene Funktion nicht korrekt gearbeitet hat) belasse ich es in der Regel bei return false.
In Objective-C könnte ich wohl welche verwenden, aber die Sprache ist dem Anschein nach zu robust, um häufig welche zu benötigen. Nullpointer sind unproblematisch und bei einem Fehler kommt meistens einfach nil raus und das ist ein gültiger Wert für weitere Funktionen. Ich könnte strikt sein und das Programm abschmieren lassen, wenn es beispielsweise eine Datei nicht finden kann. Nur mach' ich das nicht.
In Java ganz eindeutig. […] wenn man nicht jeden zweiten Funktionsaufruf in try/catch wickelt, gilt das als schlechter Stil (so viel übrigens zu C++s häßlichen ifs).
...
Das habe ich bisher weder irgendwo gesehen noch gehört. o_O" Im Regelfall genügen doch in den meisten Funktionen ein bis zwei solcher Blöcke, unterschiedliche Fehler aus den einzelnen Aufrufen/Statements kann man zur Not ja meist auch am Exception-Typ erkennen. Also ich weiß jedenfalls nicht, woher du das hast, scheint mir auch im Zusammenhang mit dem Rest des Satzes mehr ein Vorurteil zu sein.
Und in C (i.e.: bei der Fehlercode-Zurückliefer-Methode) kommt man um das händische Prüfen jedes einzelnen Rückgabewertes ja eindeutig nicht herum, ohne potenzielle Fehlerquellen im Code zu lassen.
(Ahja, und es ist zumindest für mich nicht ersichtlich, worauf sich dein erster Satz im Zitat bezieht. *kratz*)
--
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.
Das habe ich bisher weder irgendwo gesehen noch gehört. o_O" Im Regelfall genügen doch in den meisten Funktionen ein bis zwei solcher Blöcke, unterschiedliche Fehler aus den einzelnen Aufrufen/Statements kann man zur Not ja meist auch am Exception-Typ erkennen.
...
Nur dann, wenn ein Fehler in einer aufgerufenen Methode bedeutet, daß die komplette aufrufende Methode nicht mehr funktioniert. Wenn dem nicht so ist, hat man kleine Blöcke mit try/catch(/finally) drumrum. Wenn das öfters vorkommt, kann der Code beeindruckend häßlich werden. Letztenendes macht man im Wesentlichen das Gleiche wie bei C(++), nur daß man statt Fehlerkonstanten Aufrufe von Methoden der Exception hat und sich Sprünge spart, falls doch die ganze Methode ruiniert wird.
Zitat
(Ahja, und es ist zumindest für mich nicht ersichtlich, worauf sich dein erster Satz im Zitat bezieht. *kratz*)
In Java ganz eindeutig. Aber in Java geht es ohnehin darum, ein gegebenes Problem unter Einsatz möglichst vieler Klassen zu lösen und wenn man nicht jeden zweiten Funktionsaufruf in try/catch wickelt, gilt das als schlechter Stil (so viel übrigens zu C++s häßlichen ifs).
...
Ist das so? Hier lernen wir, das wir möglichst wenig damit arbeiten sollen und eben nur die checked fangen, alles anderen ist schlechter Code oder unglückliche Umstände.
Ich wüsste auch nicht warum sich einfache abfragen in einen Try-Block packen soll, wenn ich doch schon mit dem If den Fehler gefangen habe.
Ach, asserts mit Exceptions zu vergleichen ist doch schon fast etwas unhuebsch. Die Idee ist ja doch eine Andere: Bei Exceptions ist der Fehlerfall Teil des Ergebnisses, was bei Asserts wiederum nicht der Fall ist.
Beides hat seine Daseinsberechtigung. Dementsprechend mische ich auch beides. So verwende ich Asserts in erster Linie zur Flusskontrolle, während ich Exceptions zur Berichterstattung von Fehlern, mit der Umwelt, verwende.
Der Rest ergibt sich eigentlich genau hier heraus.
Was für Fehler ich nun per Exceptions, oder Return-Wert erstatte, kommt in erster Linie darauf an, was ich gerade mache. In meinem Hauptprojekt, beispielsweise, verwende ich kaum eine Exception aktiv. Fast alle Grundbibliotheken, die ich verwende, werfen keine Exceptions, und die Fehler die, in den einzelnen Phasen meines Programmes auftreten können, müssen in der Regel ohnehin geordnet angezeigt werden. Ungewollte Zustände müssen zwanghaft zum Abbruch führen. Genau so verwende ich meine API nie so, als dass man sich mit Exceptions etwas sparen würde. Ganz im Gegenteil: Dort wo sie schoen anzuwenden wären, würde ich meinen Usern damit das Leben schwer machen.
Hingegen werde ich allerdings demnächst wohl alle fopen-calls aus meinen Plugins heraus schreiben, um auf etwas Exception-werfendes umzusatteln. Zur Zeit sind da nämlich einfach keine Checks, ob ein Call nun gut geht, oder eben nicht. Wenn man so herum zu wenig Speicherplatz hat, wird das Programm einfach nur sterben, ohne, dass irgend etwas berichtet wird. Da ist an dann doch besser dran, wenn man gleich auf etwas abstrahierenderes umsteigt, als wenn man sich das Leben unnötig, mit 1000 if-abfragen, schwer macht. Die klassische C-Alternative, um sich die ganzen Abfragen zu sparen, passt mir zu wenig in den restlichen Code. ^^"
\Jesus
Gerade Stream-Operationen sind doch ein gutes Beispiel, wie man Exception anwenden sollte. Bei einheitlichen APIs, mit guten Exceptions, spart mans ich definitiv etwas.
Btw liest sich der lange Post von dir so, als wuerdest du einen Fisch haben wollen. :P
Zitat
Und in C (i.e.: bei der Fehlercode-Zurückliefer-Methode) kommt man um das händische Prüfen jedes einzelnen Rückgabewertes ja eindeutig nicht herum, ohne potenzielle Fehlerquellen im Code zu lassen.
...
Denk mal etwas Zeigerlastiger. :P
--
"When I was in college, there were certain words you couldn't say in front of a girl," "Now you can say them, but you can't say 'girl." - Tom Lehrer
Was willst du mir damit sagen? ^^"
Wenn ich zeigerlastiger denke, denke ich: Fehlerfall => return NULL; => Segmentation fault => $ gdb … # STIIIIIIRB!!!!!. <__<
--
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.
Uh Exceptions... Leider kann ich nur von Java berichten und was ich da gelernt habe ließ mich genau auf die Fragen stoße die du die gestellt hast: "Welchen Sinn machen sie?" In Java sind ja so gut wie alle Exceptions bereits vorhanden und eigene lohne sich imho nur für das hochpropagieren oder bei den erwähnten komplexen Rekursionen.
Ansonsten finde ich, das es den Code unnötig auf bläht.
Ich weiß nicht wie es in C++ ist, aber in Java gibt es ja sowieso checked und uncheked Exceptions, also solche die gefangen werden müssen und solche die nicht gefangen werden müssen. So wird man in IDE's soweiso sofort darauf aufmerksam gemacht das man hier einen Try-Block benötigt oder aber die Exception propagiert.
...
Wenn ich das sagen darf: Du denkst hier falsch. Du solltest dir nicht die Frage stellen, ob Exceptions Sinn machen (bzw. welchen Sinn), sondern wann sie Sinn machen und wie man sie sinngemäß einsetzt. Exceptions sind ein mächtiges Werkzeug um deine Programme verlässlicher und wartungsfreundlicher zu machen, in dem Sinn, dass die Fehlerfindung, sowie die Fehlerbehandlung extrem vereinfacht wird im Vergleich zu allen Ansätzen bevor Exceptions eingeführt wurden.
Ganz unabhängig von der Sprache teilst du deine Ausnahmefälle in zwei Kategorien auf:
Ausnahmefälle von denen dein Programm sich erholen kann: Das sind alle Fehler, die mit der Korrektheit deines Programms nichts zu tun haben und Quellen wie etwa fehlerhaften Userinput, fehlende Dateien, Datenbankfehler, usw. haben. Das sind die checked Exceptions in Java.
Und Ausnahmefälle von denen es sich nicht erholen kann: Diese sind grundsätzlich Bugs in deinem Programm (welchen Sinn würde es machen, sich von einem Bug zu erholen? Das würde den Bug nur verschleiern und dein Programm inkonsistent machen), aber auch fatale wie ein erschöpfter Heap oder Vergleichbares. Das sind die unchecked Exceptions in Java, die alle von RuntimeException ableiten. In der Regel werden diese Exceptions viel öfter geworfen als die aus der oberen Sparte, was auch ein Grund ist, wieso du sie nicht in deiner API deklarieren musst.
Ehrlich gesagt finde ich auch nicht wirklich Gefallen daran gezwungen sein zu müssen checked Exceptions zu behandeln, aber das ist eher bedingt durch die Faulheit zu der C++ verleitet und hat nichts damit zu tun, dass ich diesen Zwang sinnlos finde. Im Gegenteil, ich finde es ist gerechtfertigt und macht das Programm viel konsistenter, beispielsweise im Gegensatz zu C++-Programmen/Bibliotheken, in denen man oft nicht weiß, ob, welche und bei welchem Input Exceptions geworfen werden. Dass C++ erlaubt mit allem zu werfen, was einem unter die Finger kommt, habe ich ja bereits erwähnt. Also ja, Javas Ideologien blähen den Code durchaus auf, aber in einem für Java akzeptablen Rahmen (bei sinngemäßem Einsatz) und bestimmt nicht unnötigerweise.
Zitat von R.D.
Ich wüsste auch nicht warum sich einfache abfragen in einen Try-Block packen soll, wenn ich doch schon mit dem If den Fehler gefangen habe.
...
Du hast dich wahrscheinlich nur unglücklich ausgedrückt, aber eine Exception kannst du nicht mit einem If-Block abfangen.
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.
Zitat von Mog
Ach, asserts mit Exceptions zu vergleichen ist doch schon fast etwas unhuebsch. Die Idee ist ja doch eine Andere: Bei Exceptions ist der Fehlerfall Teil des Ergebnisses, was bei Asserts wiederum nicht der Fall ist.
Beides hat seine Daseinsberechtigung. Dementsprechend mische ich auch beides. [...]
...
Klar. Auf Assertions würde ich auch nicht verzichten, egal ob ich gerade Exceptions verwende, oder nicht. Wie der Name bereits sagt, sind sie eine Zusicherung an die Korrektheit des Programms und beim DbC-Pattern sowieso nicht wegzudenken.
@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.
Ansonsten komme ich im Moment auch nicht darauf, was Mog mit "denk mal etwas zeigerlastiger" gemeint hat, wenn er nicht gerade den Umstand meinte, dass die Überprüfung schwarz-weiß ist. ^^
Ich hab mir den Artikel mal durchgelesen (warum nicht schon früher weiß ich auch nicht). Ist sehr interessant und offenbarend für mich gewesen. In der FH hier hatte man uns das Ganze so beigebracht das man einen Try-Block macht und in DIESEM ein Abfrage macht und die Exception wirft. Ich fand eben das immer irgendwie fraglich.
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.
Zitieren
