cosmochaosmaker hat gesagt.:
Meine Güte,
dein Wissen macht mir Angst.
Du scheinst ein einer dieser "älteren" Cracks von damals zu sein.
Keine Sorge, es gibt verschiedene Formen des Wissens. Ich habe als 15 Jähriger die ersten Programme geschrieben, wie vermutliche viele andere im ähnlichen Alter ebenso.
Es war halt in der frühen Mitte der 80'er, in der, so man interessiert war, mit Homecomputern nicht nur spielend sondern auch programmiertechnisch auseinandersetze. Damals hatte ich vor allem Neugier und teilweise Gelegenheit mich mit einigen verschiedenen Programmiersprachen zu beschäftigen, wobei es weniger in große Tiefen ging sondern mehr um die Philosophien der jeweiligen Sprachen. Insofern habe ich, selbst wenn ich mal so etwas wie Spezialwissen gehabt haben sollte, mich mehr für das prinzipielle interessiert.
cosmochaosmaker hat gesagt.:
Vermeidest Du jetzt prinzipiell das Ergebnis zurückzugeben
und verwendest anstelle ReturnCodes und entscheidest dann den Wert auszulesen,
den Du derweil woanders hin gespeichert hast?
Ich bin mir nicht sicher, ob du da komplizierter denkst als es eigetnlich ist. Wenn Dir z.B. ein zugriff auf eine DB-Tabelle nicht geklappt hat, weil keine Connection, Statement falsch oder Constraint, der sich beschwert etc, ist es sinnlos irgendwelche Daten einlesen zu wollen. In heutigen Umgebungen bekommst du eine Exception und der fachliche code muss sich nicht damit rumschlagen und sieht halt auch fachlich aus. In einer Umgebung ohne Exception (so wie es halt früher war) hast Du mit einem if then else oder case-anweisung (in c ähnlichen Sprachen switch-anweisung) halt darauf reagiert, das ist eigentlich alles. Also so wie im 3. Beipiel.
cosmochaosmaker hat gesagt.:
Ist das nicht ein bissel "pessimistisch programmiert"?.
...
cosmochaosmaker hat gesagt.:
Vor allem wenn man von der Funktion einen Typ anstatt irgend einen Zahlenwert erwartet.
Ja es ist pessimistisch programmiert, man tut es ja nicht mit jeder beliebingen Funktion, sondern nur dann wenn etwas nicht klappen könnte, sei es aus Technischen oder aus Programmeirfehlergründen.
Normalerweise ist ja sowas nur dann der Fall wenn man mit anderen Systemen kommuniziert, typisches Beispiel DB oder Netzwerk.
Der prozedurale Ansatz wird in heutigen modernen Systemen natürlich nicht mehr gemacht, dafür gibt es halt mittlerweile Exception-Handling.
cosmochaosmaker hat gesagt.:
Es gibt natürlich auch andere Scenarios wo vor dem Verwerten des Ergebisses,
der Erfolgsstatus gebraucht wird.
Quasi wenn Du Du dir sowas wie ein Objekt baust welches mit Read() usw arbeitet.
(wie beim IO.Stream) Dann ist es logischerweise praktikablerer mit einer Funktion,
die Daten zu lesen zu prüfen ob und wieviel gelesen werden konnte.
Oder wie Du schon sagtest best. StringFunktionen.
StringFunktionen sind ein typisches Beispiel wo das ganze ohne Exceptions gelöst wird, weil solche Fehler wirklich zu oft passieren können und vermutlich ja gar keine Exception-würdige Situation ist.
cosmochaosmaker hat gesagt.:
Das bläht sich dann alles so auf und wird für mich unübersichtlich.
Genau das ist ja auch der Grund, warum man ungewöhnliche technische Probleme eben nicht mehr mit Fallunterscheidungen beglückt.
cosmochaosmaker hat gesagt.:
Sollte aber auch nur eine Notbremse sein find ich.
Exceptions als Programmflusssteuerung zu verwenden ist Schwachsinn.
Wir beide sind da absolut konform, man sollte Exceptions nur als solche verwenden was sie nunmal auch sind, nähmlich Ausnahmen!
cosmochaosmaker hat gesagt.:
Ich denke es ist nur ein Ding der Notwendigkeit.
Also Scenarios, bei denen der Erfolgsstatus bekannt sein muss,
bevor das Ergbnis verwertet wird.
Richtig, entweder man benötigt ein Ergebnis und es wäre falsch keines zu bekommen oder ein Ergebnis nicht zu bekommen hat innerhalb der Anwendung einen Semantischen Sinn.
Wo es allerdings Sinnvoll sein kann in seiner eigenen Anwedung Exceptions zu werfen ist z.B. wenn sichergestellt werden soll, dass die einer Mehtode dargebrachten Argumente koreckt sind oder nicht. Ein typisches Beispiel welches ich da rausgreifen mag wären z.B. sogenannte Funktionscodes.
Nehmen wir mal an eine routine erwartet als Argument unteranderem für die nähere Verarbeitungsspezifizierung einen sogenannten Funktionscode aus einer fest definierten Menge, dann kann es sinnvoll sein diesen code auf gültigkeit abzutesten einfachste Möglichkeit wäre das in einem switch/case - Konstrukt
Code:
// erlaubte funcCodes (TUH_DIES, TUH_DAS)
func1 (int funcCode, Object arg1, Object arg2)
{
switch (funcCode)
{
case TUH_DIES:
....
break;
case TUH_DAS:
....
break;
default: // in der Hoffnung, dass es nie zu dieser Exception kommt
throw new IllegalArgumentException("falscher Code"+funcCode);
}
}
Mal abgesehen, dass IllegalArgumentException vermutlich in C# etwas anders heißen mag, ist der Sinn dieses Konstruktes der, dass man sicher ist, dass die Routine etwas tut oder aber sich beschwert. Damit wird sichergestellt, dass der Programmierer der die Routine aufruft dies auch zumindest in diesem Beispiel mit einem erlaubten Funktionscode tut. Trifft man also eine solche Exception in der Ausführung an, darf man sicher sein, das etwas zu korrigieren ist. Insofern ist aus meiner sicht es nicht notwendigerweise falsch in seinem Programm auch selbst Exceptions zu werfen, mit unter ersparrt das gerade in solchen Szenarios unnötige Analyse Zeit.
Aber wie Du schon bemerkt hast und auch ich immer wieder nur betonen kann, sind Exceptions als Ausnahmezustand anzusehen.
Takidoso
