Verständnisfrage zu Exit

[Delphi-Laie]

Zitat:

Zitat von kagi3624 (Beitrag 1475134)

Als C/C++ Vorgeschädigter denke und schreibe ich immer noch ein result hin und erwarte das ende der Funktion. Nun, da Delphi ja bei einem result nicht die Funktion beendet, dachte ich exit zu benutzen, davor wird in der Delphi Basics Hilfe aber gewarnt. Was spricht eigentlich dagegen sowas zu schreiben und sich anzugewöhnen

Delphi-Quellcode:

if A then begin
  result := 1;
  exit;
end
else if B then...

Die ganzen nachkommenden else if Abfragen brauch ich ja nicht durchzugehen, wenn ich meine Funktion hier beenden will?

Dagegen spricht nichts.

Ich verstehe die Frage bzw. das Problem nicht.

In C und seinen Derivaten werden mit return der Rückgabewert festgelegt und die Funktion verlassen. In Pasal, Delphi und seinen Derivaten gibt es dafür zwei getrennte Befehle. Der Funktionswert kann innerhalb der Funktion sogar beliebig oft geändert werden. Er sollte aber bei jedem Funktionsdurchlauf wenigstens einmal einen Wert zugewiesen bekommen, ansonsten ist der Rückgabewert unbestimmt.

[Benmik]

Auch wenn das Thema so ziemlich abgehandelt ist, interessiert mich doch noch ein Aspekt.

Ich arbeite im Moment an einer EXIF-Unit. Die Exiferei ist ein Gebiet, auf dem man alles, wirklich alles pausenlos abprüfen muss, weil dort das reine Faustrecht herrscht (ja, Microsoft und Adobe, ihr seid gemeint!). Dementsprechend ist ein Result ausschließlich am Ende völlig illusorisch, weil es nur noch boolesche Funktionen gibt und die voll sind von Results.

Dementsprechend wäre für die Funktionen Folgendes sinnvoll:

Delphi-Quellcode:

Result := KlapptDas1;
Result := Result and KlapptDas2;
Result := Result and KlapptDas3;
Result := Result and KlapptDas4;
If Result then begin
 ... // jetzt kann es losgehen

Vor allem auch für das Debuggen ist das enorm praktisch, weil man sich durchF8en kann und sofort sieht, wenn Result False wird. Und sehr übersichtlich ist es auch, was ja für Code nicht das Schlechteste ist. Andererseits sieht man sowas im Proficode nie, woraus ich schließe, dass es aus mir unerfindlichen Gründen verpönt ist (Himitsu, lass das "h" weg, das kommt von poena!). Mein Gedanke ist nun: Der Compiler lässt das alles doch sowieso nicht so, wie wir das hinschreiben. Es kann doch oft sein, dass die "offziellen" Elaborate überhaupt kein anderes Ergebnis erbringen als der Code oben, und schon mal überhaupt keinen Geschwindigkeitsunterschied. Ist es nicht erwägenswert, übersichtlichen und debuggingfreundlichen Code zu schreiben, der dann sowieso vom Compiler optimiert wird?

[dummzeuch]

Zitat:

Zitat von Benmik (Beitrag 1475280)

Ist es nicht erwägenswert, übersichtlichen und debuggingfreundlichen Code zu schreiben, der dann sowieso vom Compiler optimiert wird?

Um mal Knuth zu ziteren:

Zitat:

"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

Solange es also kein Performance-Problem gibt, sollte man nicht optimieren. Wenn es eines gibt, sollte man erst durch Timing herausfinden, wo man am meisten erreichen kann.

Angewandt auf Dein Beispiel: Debugging-freundlicher Code ist guter Code, es sei denn, er ist nachweisbar ein Performance-Problem.

[Delphi.Narium]

Zitat:

Zitat von Benmik (Beitrag 1475280)

Auch wenn das Thema so ziemlich abgehandelt ist, interessiert mich doch noch ein Aspekt.

Ich arbeite im Moment an einer EXIF-Unit. Die Exiferei ist ein Gebiet, auf dem man alles, wirklich alles pausenlos abprüfen muss, weil dort das reine Faustrecht herrscht (ja, Microsoft und Adobe, ihr seid gemeint!). Dementsprechend ist ein Result ausschließlich am Ende völlig illusorisch, weil es nur noch boolesche Funktionen gibt und die voll sind von Results.

Dementsprechend wäre für die Funktionen Folgendes sinnvoll:

Delphi-Quellcode:

Result := KlapptDas1;
Result := Result and KlapptDas2;
Result := Result and KlapptDas3;
Result := Result and KlapptDas4;
If Result then begin
 ... // jetzt kann es losgehen

Vor allem auch für das Debuggen ist das enorm praktisch, weil man sich durchF8en kann und sofort sieht, wenn Result False wird. Und sehr übersichtlich ist es auch, was ja für Code nicht das Schlechteste ist. Andererseits sieht man sowas im Proficode nie, woraus ich schließe, dass es aus mir unerfindlichen Gründen verpönt ist (Himitsu, lass das "h" weg, das kommt von poena!). Mein Gedanke ist nun: Der Compiler lässt das alles doch sowieso nicht so, wie wir das hinschreiben. Es kann doch oft sein, dass die "offziellen" Elaborate überhaupt kein anderes Ergebnis erbringen als der Code oben, und schon mal überhaupt keinen Geschwindigkeitsunterschied. Ist es nicht erwägenswert, übersichtlichen und debuggingfreundlichen Code zu schreiben, der dann sowieso vom Compiler optimiert wird?

Dein Beispiel ist für mich etwas absolut normales.

Und, wenn ich auch kein Freund vom Exit bin, hier kann bei mir dann durchaus mal sowas vorkommen:

Delphi-Quellcode:

Result := KlapptDas1;
Result := Result and KlapptDas2;
Result := Result and KlapptDas3;
Result := Result and KlapptDas4;
If not Result then exit;
// weil hier einfach ggfls. noch "furchtbarviel" Code folgen kann.

Das entspricht dem weiter oben mehrfach Angesprochenen:

Am Anfang werden die Grundvoraussetzungen geprüft, sind die nicht erfüllt, dann raus per Exit.

Danach kommt dann die Erledigung der eigentlichen Aufgabe.

[bernau]

Zitat:

Zitat von Benmik (Beitrag 1475280)

Dementsprechend wäre für die Funktionen Folgendes sinnvoll:

Delphi-Quellcode:

Result := KlapptDas1;
Result := Result and KlapptDas2;
Result := Result and KlapptDas3;
Result := Result and KlapptDas4;
If Result then begin
 ... // jetzt kann es losgehen

Grade das ist doch prädistiniert für ein Exit;

Delphi-Quellcode:

if not KlapptDas1 then
  Exit;
if not KlapptDas2 then
  Exit;
if not KlapptDas3 then
  Exit;
if not KlapptDas4 then
  Exit;
 ... // jetzt kann es losgehen

Breakpoint auf alle Exit und du springst sofort auf den betreffenden Exit ohne mit F8 durch zappen zu müssen.

Immer wenn ich irgendwo beim Refactoring bin, versuche ich immer Vorabbedingunge in ein Exit hineinzuverfrachten.

[Benmik]

Zitat:

Zitat von dummzeuch (Beitrag 1475281)

Um mal Knuth zu ziteren:

Das Zitat von Knuth kannte ich und ich finde, dass sollte man mal in goldenen Lettern irgendwo anschlagen.

Zitat:

Zitat von bernau (Beitrag 1475283)

Breakpoint auf alle Exit und du springst sofort auf den betreffenden Exit ohne mit F8 durch zappen zu müssen.

Das ist ja schlau.
Vor Kurzem hat Himitsu sein

Delphi-Quellcode:

If Bedingung = Erfüllt then
  Sleep(0)

gepostet und da habe ich mich gefragt, warum ich nicht selbst darauf gekommen bin.

Ansonsten - OK, da bin ich ja beruhigt.:thumb:

[Stevie]

Zitat:

Zitat von Benmik (Beitrag 1475280)

Mein Gedanke ist nun: Der Compiler lässt das alles doch sowieso nicht so, wie wir das hinschreiben. Es kann doch oft sein, dass die "offziellen" Elaborate überhaupt kein anderes Ergebnis erbringen als der Code oben, und schon mal überhaupt keinen Geschwindigkeitsunterschied. Ist es nicht erwägenswert, übersichtlichen und debuggingfreundlichen Code zu schreiben, der dann sowieso vom Compiler optimiert wird?

Wären wir in einem C++ Forum, würd ich dir zustimmen. Ist bei Delphi nur leider nicht so und man muss dem Compiler laufend unter die Arme greifen - aber ja, wir reden hier über die 3%, wo das relevant ist.

[Uwe Raabe]

Zitat:

Zitat von bernau (Beitrag 1475283)

Grade das ist doch prädistiniert für ein Exit;

Delphi-Quellcode:

if not KlapptDas1 then
  Exit;
if not KlapptDas2 then
  Exit;
if not KlapptDas3 then
  Exit;
if not KlapptDas4 then
  Exit;
 ... // jetzt kann es losgehen

Breakpoint auf alle Exit und du springst sofort auf den betreffenden Exit ohne mit F8 durch zappen zu müssen.

Auf eine Zeile mit einem simplen Exit kannst du aber keinen Breakpoint setzen. Nur wenn mit dem Exit ein Result zurückgegeben wird geht das.

Delphi-Quellcode:

if not KlapptDas1 then
  Exit(False);
if not KlapptDas2 then
  Exit(False);
if not KlapptDas3 then
  Exit(False);
if not KlapptDas4 then
  Exit(False);
 ... // jetzt kann es losgehen

[bernau]

Zitat:

Zitat von Uwe Raabe (Beitrag 1475290)

Auf eine Zeile mit einem simplen Exit kannst du aber keinen Breakpoint setzen. Nur wenn mit dem Exit ein Result zurückgegeben wird geht das.

Ähm. ja. Stimmt. :oops:

[Benmik]

Spielverderber! Trotzdem guter Tipp für mich: Das

Delphi-Quellcode:

exit(False)

ist die Regel und notfalls schreibe ich es hin, auch wenn am Anfang der Routine

Delphi-Quellcode:

Result := False;

steht. Kann man ja wieder wegmachen, wenn das Debugging vorbei ist.

[himitsu]

Zitat:

Zitat von Benmik (Beitrag 1475295)

Kann man ja wieder wegmachen, wenn das Debugging vorbei ist.

Ähhh neee?
Dann verhält sich dein Programm ja beim Debuggen womöglich anders, als in echt, was schon ein bissl sinnlos wäre.

Und natürlich geht es nur, wenn es eine Funktion und keine Prozedur ist. Und natürlich auch nur mit Boolean als Result. :stupid:

[Benmik]

Nein, ich meinte doch Folgendes:

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  Result := False;
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  ....

Das "False" wäre ja nicht nötig, kann man zum Debuggen rein und hinterher wieder rausmachen.
(Oder man geht nach Hagen und macht das "Result := False" erst gar nicht hin, aber ich bin da gern auf der sicheren Seite.)

[bernau]

Zitat:

Zitat von Benmik (Beitrag 1475298)

Nein, ich meinte doch Folgendes:

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  Result := False;
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  ....

Das "False" wäre ja nicht nötig, kann man zum Debuggen rein und hinterher wieder rausmachen.
(Oder man geht nach Hagen und macht das "Result := False" erst gar nicht hin, aber ich bin da gern auf der sicheren Seite.)

In vielen Fällen spricht erst mal ja nichts dagegen, aus einer Procedure eine Function zu machen.

Das

Delphi-Quellcode:

Result := False;

kann man nach hinten verschieben.

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  Result := True;
  ....

Grade dein Procedurename/Funktionsname ist für ein Result geeignet. Laden des Jpeg hat funktioniert oder eben nicht.

[bernau]

Zitat:

Zitat von himitsu (Beitrag 1475296)

Und natürlich geht es nur, wenn es eine Funktion und keine Prozedur ist. Und natürlich auch nur mit Boolean als Result. :stupit:

Warum nur mit Boolean als Result?

[himitsu]

Weil das Exit(False) sonst knallt?

Und ja, diese Exit sind hier schon bissl blöd.
Es ist toll, wenn die Prozedur nicht nur Exit macht, sondern wenigstens noch Funktion noch ein False sagt,

aber erstmal wird oft genug vergessen das Result von Funktionen auszuwerten
und dann macht es die Fehlerbehandung und auch Fehlersuche extrem spannend, wenn man nicht weiß warum die Funktion nichts machte.



Exceptions sind schon was Tolles, das auch gute Infos geben könnte.

[jfheins]

Zitat:

Zitat von himitsu (Beitrag 1475311)

aber erstmal wird oft genug vergessen das Result von Funktionen auszuwerten
und dann macht es die Fehlerbehandung und auch Fehlersuche extrem spannend, wenn man nicht weiß warum die Funktion nichts machte.

Da gefällt mir übrigens sehr der Ansatz von Rust (ohne, dass ich das bisher selbst probiert habe): Die Funktion gibt einen Result-Typen zurück, und man muss prüfen ob es ein SuccessResult ist, bevor man an den Wert dran kommt. (https://doc.rust-lang.org/stable/rus...or/result.html)
Bzw. Im Regelfall nimmt man das Result einer Funktion und hängt einfach eine Operation an den Erfolg an. Allso ein automatisches

Delphi-Quellcode:

res := strtoint(text)
if res.Success then
  Result := TResult.Create(Success, res.Value * 2)
else
  Result := res

Dürfte in Delphi aber kniffelig umzusetzen sein, weil es als varianter record immer den Zugriff auf den Erfolg zulässt und/oder (als Klassenhierarchie) den Aufrufer mit der Speicherfreigabe "beglückt".

[Benmik]

Zitat:

Zitat von bernau (Beitrag 1475303)

Warum nur mit Boolean als Result?

Es ist vielleicht nur ein vorübergehender Zustand und auch der EXIFerei geschuldet, aber ich habe angefangen, praktisch alle Prozeduren in boolesche Funktionen umzuwandeln, bei denen der Wert per

Delphi-Quellcode:

var

übergeben wird.
Erstens kann man dadurch mehr als einen Wert übergeben, und zweitens finde ich den Aufruf

Delphi-Quellcode:

If BestimmeHeaderPos(HeaderPos) then begin
  MachWasMitHeaderPos;

viel praktischer als

Delphi-Quellcode:

HeaderPos := BestimmeHeaderPos;
If HeaderPos > 0 then begin
  MachWasMitHeaderPos;

[himitsu]

Zitat:

Zitat von jfheins (Beitrag 1475319)

Die Funktion gibt einen Result-Typen zurück, und man muss prüfen

Ich war mir sicher, dass es im Delphi/Pascal auch einen Compilerschalter gab, wo der Compiler einen Fehler oder eine Warnung warf, wenn das Result einer Funktion nicht ausgewertet wird. (nicht in einem IF, an eine Variable zugewiesen oder als Parameter genutzt)

Aber ich find grade nicht.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1475325)

Ich war mir sicher, dass es im Delphi/Pascal auch einen Compilerschalter gab, wo der Compiler einen Fehler oder eine Warnung warf, wenn das Result einer Funktion nicht ausgewertet wird.

Das ist Teil des Compiler-Schalters $X (Erweiterte Syntax):

Zitat:

Dient nur der Abwärtskompatibilität. Verwenden Sie diese Option (entspricht {$X-}) nicht in Ihren Delphi-Anwendungen. Mit dieser Option wird die erweiterte Syntax von Delphi aktiviert oder deaktiviert:

Funktionsanweisungen. Im Modus {$X+} können Funktionsaufrufe als Prozedurenaufrufe verwendet werden, d. h. das Ergebnis eines Funktionsaufrufs kann ignoriert werden, anstatt an eine andere Funktion übergeben oder in einer Operation bzw. Zuweisung verwendet zu werden. Im Allgemeinen werden die von einer Funktion ausgeführten Berechnungen durch das Funktionsergebnis repräsentiert, das nicht ignoriert werden sollte. Manchmal führen Funktionen aber lediglich eine bestimmte Operation durch (z. B. einer globalen Variablen einen Wert zuweisen) und geben keinen Wert zurück, der weiterverwendet werden kann.

Result-Variable. Wenn die Option aktiviert ist (entspricht {$X+}), kann die vordefinierte Result-Variable für den Rückgabewert der Funktion verwendet werden.

Nullterminierte Strings. Wenn diese Option aktiviert ist, können Delphi-Strings nullbasierten Zeichen-Arrays (array[0..X] of Char) zugewiesen werden, die mit PChar-Typen kompatibel sind.

Leider ist bei $X- auch die Verwendung von Result anstatt des Funktionsnamen für den Rückgabewert nicht mehr möglich. Das wird aber aktuell soviel verwendet, dass vermutlich kaum ein Programm noch mit $X- compileren würde.

[Stevie]

Zitat:

Zitat von jfheins (Beitrag 1475319)

Da gefällt mir übrigens sehr der Ansatz von Rust (ohne, dass ich das bisher selbst probiert habe): Die Funktion gibt einen Result-Typen zurück, und man muss prüfen ob es ein SuccessResult ist, bevor man an den Wert dran kommt.

Puh, das driftet jetzt aber sehr ab - Result<T,E> in Rust ist aus der funktionalen Programmierung, um die Abwesenheit eines Wertes (in anderen Sprachen oft mit einem Nullable<T> modelliert), oder einen Fehler ohne Exception raising darzustellen, womit man sehr gut pure Funktionen aneinanderketten kann. Siehe auch die Präsentation "Railway Oriented Programming" von Scott Wlaschin.

Ich hab über diese Thematik übrigens auch schon gebloggt:
https://delphisorcery.blogspot.com/2...nil-maybe.html
https://delphisorcery.blogspot.com/2...or-delphi.html

Kommt jetzt aber arg vom Thema "Exit oder nicht" ab ;)

[HeZa]

Zitat:

Zitat von bernau (Beitrag 1475302)

In vielen Fällen spricht erst mal ja nichts dagegen, aus einer Procedure eine Function zu machen.

Das

Delphi-Quellcode:

Result := False;

kann man nach hinten verschieben.

Delphi-Quellcode:

Function LeseJPGEin(DatnameMV:string):Boolean;
begin
  If not DateiVorhanden
    then exit(False);
  If not HeaderOK
    then exit(False);
  If not EndianOK
    then exit(False):
  Result := True;
  ....

Grade dein Procedurename/Funktionsname ist für ein Result geeignet. Laden des Jpeg hat funktioniert oder eben nicht.

Tut mie leid, gerade diese Routine schreit danach ein Prozedur zu sein die im Fehlerfall eine Exception wirft.

Denn wenn der Kunde anruft und sich beschwert, dass die JPEG-Datei xyz.jpg nicht geladen werden kann, will ich wissen wie es dazu kam: War die Datei vorhanden? War der Header Okay? War das Endian Okay? Zumal diese Funktion eh Exceptions werfen könnte, z.B. weil der Dateipfad falsch ist, die Datei gesperrt ist, das Netzlaufwerk zum Pfad nicht gemountet ist. Und auch weil die Datei nicht vorhanden ist, weil DateiVorhanden eine RaceCondition darstellt.

Wenn es Interessante Gründe gibt warum eine Methode Fehlschlägt sollte man diese nicht hinter einem Boolean Result verstecken. Davon sollte nur abgewichen werden, wenn jemand "beweist", dass das für die Anwendung ein Performance-Problem darstellt. Dann könnte ich mich evtl. mit der hässlichen alternative

Delphi-Quellcode:

function LeseJPGEin(DatnameMV:string; var FehlerMeldung: string):Boolean;

anfreunden.

Ciao HeZa

[kagi3624]

Zitat:

Zitat von Delphi-Laie (Beitrag 1475269)

Dagegen spricht nichts.

Ich verstehe die Frage bzw. das Problem nicht.

http://www.delphibasics.co.uk/RTL.as...xpandCode1=Yes

Zitat:

Warning : use with caution - jumping is a concept at odds with structured coding - it makes code maintenance difficult.

[Uwe Raabe]

Zitat:

Zitat von HeZa (Beitrag 1475343)

Tut mie leid, gerade diese Routine schreit danach ein Prozedur zu sein die im Fehlerfall eine Exception wirft.

Denn wenn der Kunde anruft und sich beschwert, dass die JPEG-Datei xyz.jpg nicht geladen werden kann, will ich wissen wie es dazu kam: War die Datei vorhanden? War der Header Okay? War das Endian Okay? Zumal diese Funktion eh Exceptions werfen könnte, z.B. weil der Dateipfad falsch ist, die Datei gesperrt ist, das Netzlaufwerk zum Pfad nicht gemountet ist. Und auch weil die Datei nicht vorhanden ist, weil DateiVorhanden eine RaceCondition darstellt.

Nirgendwo in dem Code ist ersichtlich, ob die Prüfmethoden irgendwo einen Fehler vermerken, der nach einem False-Return irgendwo ausgewertet wird. Eine Exception wäre eine Möglichkeit das zu handhaben, aber es gibt auch andere.

[bernau]

Zitat:

Zitat von HeZa (Beitrag 1475343)

Tut mie leid, gerade diese Routine schreit danach ein Prozedur zu sein die im Fehlerfall eine Exception wirft.

Exceptions empfinde ich immer so als Methode mit dem Vorschlaghammer. Ausserdem stört es mich bei Methoden, die eine Exception auslösen "könnten", immmer ein try-except einbauen zu müssen.

Eleganter finde ich ein Functionsresult. Muss ja nicht unbedingt ein boolean sein, sondern kann auch eine Fehlernummer oder ein Enum sein.

Exceptions verwende ich in der regel nur, wenn das Programm einen undefinierten Status bekommen könnte, oder wenn Eingabeparameter einen Wert haben, der eigentlich nicht vorkommen darf, dann hat die aufrufende Procedure schon einen Fehler gemacht.

[himitsu]

Die Beispiele hier sind ja normal nicht der "Normalfall", also ist es kein Problem da mit einer Exception zu reagieren.
Exceptions haben auch den Vorteil, dass sie entweder "automatisch" angezeigt werden oder man sie außerhalb und sogar viel weiter oben via Try-Except abfangen/behandeln kann.



Und ja, es gibt auch andere Wege, wo man zum Boolean-Result auch noch SetLastError verwendet, oder z.B. ein eigenes LastError(s)/LastErrorMessage(s)-Property, wenn ein Fehlercode alleine nicht genügend Infos bieten kann.

[Benmik]

Zitat:

Zitat von Stevie (Beitrag 1475341)

Puh, das driftet jetzt aber sehr ab...

Noch meldet sich Daniel ja nicht...

Zitat:

Zitat von HeZa (Beitrag 1475343)

Tut mir leid, gerade diese Routine schreit danach ein Prozedur zu sein die im Fehlerfall eine Exception wirft.

Zitat:

Zitat von Uwe Raabe (Beitrag 1475352)

Nirgendwo in dem Code ist ersichtlich, ob die Prüfmethoden irgendwo einen Fehler vermerken, der nach einem False-Return irgendwo ausgewertet wird.

Bitte die Kirche im Dorf lassen. Das ist doch nur ein Minimal-Pseudo-Beispiel.
In der Realität - wie gesagt, gegenwärtiger Erkenntniszustand - handhabe ich das unter anderem so, dass bei solchen Konstrukten alle beteiligten Funktionen durch

Delphi-Quellcode:

Try

abgesichert sind, also keine Exception weitergereicht werden kann.

Zitat:

Zitat von bernau (Beitrag 1475368)

Exceptions empfinde ich immer so als Methode mit dem Vorschlaghammer.

Genau. Jetzt driften wir noch weiter ab, aber bis Daniel einschreitet: Ich verwende die GDI+-Unit von Erik van Bilsen. Stolz verkündet Erik, er habe die "alten" Statuscodes von GDIPlus durch moderne Delphi-Exceptions ersetzt und er fügt hinzu: "This way, your error checking code doesn't interrupt the normal flow of your code, and you can respond to errors in a Delphi way." Eine für mich mehr als kryptische Aussage, denn diese Konstruktion führt dazu, dass bei der Abfrage von zum Beispiel 8 GPS-Tags bei 3.000 JPG ohne GPS-Informationen (häufiger Normalfall bei Systemkamera) es zu 24.000 Fehlermeldungen kommt.

Um auf Uwe zu antworten: In den aufgerufenen Routinen stecken Fehlercodes, im am Schluss möglichst zielgerichtet ausgewertet und erst dann dem Anwender präsentiert werden. Man nehme als Beispiel IrfanView: Das registriert beim Einlesen haufenweise Fehler, sagt aber nur dann was, wenn es wirklich notwendig ist. Weiß nicht, ob es der Weisheit letzter Schluss ist, aber ich sammle zurzeit die Fehler in einem Set und schaue am Schluss, was die beste Reaktion ist.

[mkinzler]

Zitat:

Noch meldet sich Daniel ja nicht...

Und solange, er sich nicht meldet kann man weiter in OT abdriften?

Komische Entwicklung hier im Forum (oder besser allgemein immer öfters in Foren/Social Media) :gruebel: :stupid:

[himitsu]

Ja, bei Exceptions gibt es keine "Warnungen".
Bei Exceptions kann man unterschiedliche Exception-Klassen verwenden und dann im Try-Except auch sehr leicht unterschiedliche reagieren,
aber per se ist sowas bei Exceptions nicht vorgesehn, mit einer Ausnahme, den Stillen Exceptions, abgeleitet von EAbort.
Auch z.B. einige Indy-Fehler werden vom Debugger ignoriert (die sehen da in einer Ausnahmeliste, welche man selbst erweitern kann)

Bei HRESTULT kann man unterschiedliche Level definieren, von Info, über Warning zu Error oder FatalError.
Auch der Delphi-Compler kennt sowas, also Fehler die sofort abbrechen (Fatal) oder erst am Ende (Error), wo vorher noch weitere Folgefehler sich melden dürfen.

[freimatz]

Zitat:

Zitat von mkinzler (Beitrag 1475390)

Komische Entwicklung hier im Forum (oder besser allgemein immer öfters in Foren/Social Media) :gruebel: :stupid:

Nein, nicht immer öfters. Das war schon vor 30 Jahren so und wurde unter dem Namen "kathinka law" festgestellt. (http://www.rrr.de/~kathinka/akronyme.htm)

Das ist nun aber wirklich OT ;-)

[mkinzler]

Zitat:

Nein, nicht immer öfters. Das war schon vor 30 Jahren so und wurde unter dem Namen "kathinka law" festgestellt. (http://www.rrr.de/~kathinka/akronyme.htm)

In den Foren in denen ich mich bewegt habe, war das aber um einiges seltener als früher.

[Uwe Raabe]

Zitat:

Zitat von Benmik (Beitrag 1475386)

Zitat:

Zitat von Uwe Raabe (Beitrag 1475352)

Nirgendwo in dem Code ist ersichtlich, ob die Prüfmethoden irgendwo einen Fehler vermerken, der nach einem False-Return irgendwo ausgewertet wird.

Bitte die Kirche im Dorf lassen. Das ist doch nur ein Minimal-Pseudo-Beispiel.

Das sollte ja keine Kritik an dem Code sein. Ich wollte nur verdeutlichen, dass sehr wohl eine Fehlerbehandlung außerhalb der gezeigten Source-Zeilen existieren kann. So als Alternative zu Exceptions.

[Benmik]

Zitat:

Zitat von mkinzler (Beitrag 1475390)

Und solange, er sich nicht meldet kann man weiter in OT abdriften? :gruebel: :stupid:

Moralisch nein, praktisch ja. Wird dieser Widerspruch nicht auch durch die Wahl deiner Smileys ausgedrückt?

[Stevie]

Zitat:

Zitat von mkinzler (Beitrag 1475390)

Zitat:

Noch meldet sich Daniel ja nicht...

Und solange, er sich nicht meldet kann man weiter in OT abdriften?

Komische Entwicklung hier im Forum (oder besser allgemein immer öfters in Foren/Social Media) :gruebel: :stupid:

Man könnte ja auch seine Moderatorenrechte nutzen, um Seitendiskussionen abzutrennen, anstatt nur sarkastische Kommentare abzulassen ;)

[mkinzler]

Vielleicht sollte ich dieses Forum auch verlassen. Scheine für Euch ja eh nur Abschaum zu sein!

[Benmik]

Zitat:

Zitat von mkinzler (Beitrag 1475420)

Vielleicht sollte ich dieses Forum auch verlassen. Scheine für Euch ja eh nur Abschaum zu sein!

Du mein Gott, was ist denn los? Ist doch völlig normales Geflachse hier! Keiner möchte Moderator sein, und wer doch, hat in der Regel keine Ahnung.

Zitat:

Zitat von Uwe Raabe (Beitrag 1475416)

Das sollte ja keine Kritik an dem Code sein.

Missverstanden. Dann Tschuldigung.