Zitat von
mjustin:
Zitat von
Muetze1:
Was aber wenn der Speichermanager das Create gar nicht durchführen konnte? Dann ist deine SL Variable so oder so im Eimer, egal wie rum except und finally stehen.
Und umgekehrt: wenn es schon Probleme mit dem Speichermanager gibt, dann spielt der restliche Code auch keine grosse Rolle mehr. Oder wird, damit das QM zufrieden ist, dann ein automatisches Einstecken von mehr
RAM Bausteinen ausgelöst ? :)
Wer nun nicht an Beispielen erkennt das die aufgezeigten Probleme auch nur beispielhaft sind, der hat nicht das Prinzip nicht verstanden.
TStringList hat nun nicht soviele mögliche Exceptions und eine
Exception im Konstruktor wird von ihr soweit auch nicht verwendet, von daher ist es ein Beispiel gewesen. Es gibt genug Objekte in der freien Wildbahn welche weit andere Exceptions werfen. Und es nochmals daran erinnert, dass die einzige Möglichkeit einen Konstruktor abzubrechen das werfen einer
Exception ist und somit hier nicht als Ding der Unmöglichkeit von der Hand zu weisen ist.
Und wenn du QM so witzig findest, scheint dies bei dir/euch wohl auch genauso gehandhabt zu werden und somit ist die Frage was nach deren Prüfung am Ende heraus gegeben wird.
Zitat von
Satty67:
Mal als Erweiterungsvorschlag einreichen... 8)
Wurde CodeGear/Embarcardero schon vorgeschlagen und es wird für das nächste Release überlegt, da sie die Sprache samt Compiler eh nochmals umkrempeln.
Christian Seehase
Wie der Name schon sagt, handelt es sich hier um eine Ausnahme, demzufolge finde ich es einfach sauberer mögliche Fehlerbedingungen selber zu prüfen, als es "drauf ankommen zu lassen", und die Programmsteuerung durch Exceptions zu regeln.
Und da liegt der Hund begraben: persönliche Ansichten.
Aber grundlegend hast du vollkommen Recht und ich stimme dir auch voll zu. Die Fehlerbehandlung darf durch die Nutzung der Exceptions nicht gänzlich entfallen, das ist der falsche Weg. Das habe ich so auch nie propagandiert. Eine
Exception ist immer eine Ausnahmesituation, aber eine fehlgeschlagene Funktion ist dies noch lange nicht. Von daher ist die normale Fehlerbehandlung weiterhin wichtig und gefordert. Da sind wir uns auch komplett einig, von daher hast du mich vllt. falsch verstanden.
Exceptions sind dazu gedacht auf Situationen hinzuweisen welche so nicht gedacht und/oder geplant waren. Wenn geplant war, dass eine Funktion fehlschlagen kann, dann kann sie ein entsprechenden negativen Rückgabewert o.ä. geben. Eine
Exception hingegen weist auf eine ganz andere Situation neben den geplanten Abläufen hin.
Wenn ich eine vom Benutzer ausgewählte Datei öffnen will, dann kann ich mit FileExists() prüfen ob diese existiert. Dann öffne ich sie und gehe auch davon aus diese benutzen zu können. Wenn diese aber durch einen anderen Prozess exklusiv geöffnet ist oder der Nutzer entgegen besseren Wissens uns eine schreibgeschützte Datei zum Speichern ausgewählt hat, so ist dies eine Situation die neben dem geplanten Ablaufstrang liegt. Diese Situation ist eine
Exception wert und hier auch sinnvoll. Gerade dies Beispiel zeigt auf, dass man einfach nicht alles durch vorherige Abfragen abprüfen kann. Ich könnte neben FileExists natürlich noch die Attribute prüfen, aber nützt nichts, wenn ich die Datei aufgrund von fehlenden Rechten nicht öffnen kann. Nun gut, wenn ich Zeit habe erkenne ich noch das Dateisystem und checke dann die Rechte der Datei + Rechtekontext in dem die App läuft und dann ob ich damit die Datei öffnen kann. Bringt mir auch noch nichts, wenn ein anderer Prozess diese Datei hat. Ok, also das auch noch abprüfen und dann habe ich ein Problem, wenn der Nutzer auf eine Netzwerkfreigabe gegangen ist, etc, etc, etc.
Grüsse,
Muetze1