hustbaer schrieb:
mgaeckler schrieb:
hustbaer schrieb:
mgaeckler schrieb:
Wenn die ¨Selbstheilung¨ nicht geht, ziehe ich die Signalisierung über die Rückgabe dem Werfen einer Ausnahme vor. Ausnahmen stören den Kontrollfluß
Erklär mal inwieweit das relevant ist.
Jede Störung des Kontrolflußes erschwert die nachträgliche Analyse des Quelltextes.
Ja und nein. Auf nen Einzelfall bezogen: ja. Wenn man öfter mit verschiedenen Stellen eines halbwegs konsequent aufgezogenen Programms zu tun hat: nein. Weil das ganze manuelle if-blah-else if-blub Gedöns einem den Schirm und das Hirn vollmüllt.
Wenn man sich dagegen einmal die Arbeit gemacht hat nachzuvollziehen wie die Exception-Safety in einem Programm funktioniert (also wie diverse Sentinel/Guard/... Klassen arbeiten und zusammenspielen), dann sieht man recht schnell wenn wo etwas nicht passt.
Genau so wie diese Mechanismen einem beim Programmieren Arbeit abnehmen, nehmen sie einem auch Arbeit beim Lesen/Fehlersuchen ab.
Zustimmung. Deswegen sage ich ja auch immer, daß jedes Sprachmittel, seine Berechtigung hat. Man muß halt stets abwägen, ob Ihr Einsatz nachvollziehbar ist. Exceptions sind richtig angewended ein Segen.
hustbaer schrieb:
mgaeckler schrieb:
Daher sollte sowas (z.B. return mittendrinnen, goto, break, continue, throw etc.) nur mit Bedacht eingesetzt werden.
Siehste, es ist genau umgekehrt: man sollte sich sehr sehr gut überlegen ob man in C++ anfangen will Dinge über Errorcodes zu machen die man normalerweise über Exceptions machen würde/sollte. Denn in den allermeisten Fällen muss man dann beides sicherstellen: 1x dass man überall brav die ganze widerliche manuelle Fehlerbehandlung richtig macht, UND dass das Programm trotzdem noch Exception-safe ist. Weil man in den meisten Programmen früher oder später einfach Komponenten hat die Exceptions werfen. Das fängt mit der Standard-Library an und geht mit haufenweise Thirdparty-Libraries weiter.
Und an allen Schnittpunkten try-catch zu schreiben kann ja wohl auch nicht die Lösung sein.
Wenn man sich ein ganze eigenes Framework mit Hilfe von C Libraries selbst aufbaut, dann kann man es so machen. Die Frage bleibt aber immer noch ob man es dann so machen sollte.
Richtig, die Sache mit den errorCodes hat nämlich auch üble Nachteile. Deswegen immer neu entscheiden, nie pauschale Antworten geben.
hustbaer schrieb:
Opi.
Noch nicht.
hustbaer schrieb:
Wird für die meisten Leute die eine C++ Anwendung schreiben aber reichlich egal sein, nen?
Wenn Du meinen Text aufmerksam gelesen hättest...
hustbaer schrieb:
mgaeckler schrieb:
hustbaer schrieb:
mgaeckler schrieb:
Der Grund ist ganz einfach: Dein Objekt wird abhängig von dem UI.
Genau umgekehrt: das UI wird abhängig von der anderen Klasse.
Das wiederum kratzt mich überhaupt nicht. Hast Du es schon mal geschafft, erfolgreich das UI einer Bankingsoftware nur durch Austausch der Datenklassen in ein Grafikprogramm zu wandeln?
Du hast behauptet dass durch den Check im Indexing-Operator das Objekt abhängig vom UI wird. Ich behaupte dass es umgekehrt ist. Und nu?
Das UserInterface st doch in den meisten Fällen abhängig von den Datenobjekten. Das UserInterface sollte auch genügend Wissen haben, Benutzereingben zu validieren. Stell Dir vor, das UI und die Objekte laufen auf unterschiedlichen Rechnern. Das wäre doch blöd, wenn das Frontend jedesmal über das Netzwerk das Backend befragen muß, ob die Eingabe gültig ist.
Das Backend braucht dann eigentich nur noch via assert beim Entwicklungstest prüfen.
Mfg Martin
