Seltsames Memo LoadFomFile inculde Phänomen

[Sir Rufo]

Nur mal so am Rande

Was möchtest du mit

Delphi-Quellcode:

try
  ...
except
  on E: Exception do
    Showmessage(E.message);
end;

erreichen?

Soll bei einer Exception ein Dialog mit der Fehlermeldung erscheinen?
Dann entferne diesen try .. except Block, denn die Anwendung macht das von ganz alleine!

Was du jetzt hast ist eine Funktion, die bei einer Exception die Exception-Message ausgibt (der Exception-Typ fällt unter den Tisch) und dann irgendeinen nicht kontrollierbaren Rückgabewert an den Aufrufer zurückliefert.

Wenn du Pech hast, dann siehst du diese Fehlermeldung und direkt danach die Meldung "Hurra".

Wem soll das denn nun etwas sagen?

Irgendwie gibt deine Funktion egal wie nur gesichert ein True heraus, ein False wird nie explizit gesetzt. Wahrscheinlich musst du deswegen auch den Rückgabewert auf True prüfen, sonst siehst du sehr selten Hurra.

[himitsu]

Noch besser, wenn vorher der Code abgebrochen ist, das AddParseError aufrief und der Fehlercode zufällig 0 ist, dann gibt die Funktion auch True zurück, obwohl garnicht alles abgearbeitet wurde.
Und AddParseError fügt nichts irgendwo hinzu, sondern gibt nur eine Fehlermelung aus, also eher ein ShowParseError.

Zitat von Sir Rufo:

Irgendwie gibt deine Funktion egal wie nur gesichert ein True heraus, ein False wird nie explizit gesetzt.

Ein guter beweis, daß sich niemand die Compilermeldungen ansieht und auf das hört, was man ihm dort sagt.

Zitat:

sonst siehst du sehr selten Hurra.

Eher andersrum, er bekommt zu 99,3% ein False fehlerhaft als True (<>0) geliefert
und zu 0,4% wird ein "False" genau das True (=1) ergeben.

[Dejan Vu]

Zitat von himitsu:

Ein guter beweis, daß sich niemand die Compilermeldungen ansieht und auf das hört, was man ihm dort sagt.

Und das ist der Beweis, das viele Programmierer wirklich glauben, das NOT Alle = Niemand ist. Einer liest sie nicht und Du folgst daraus 'niemand'. Tss Tss Tss. Richtig wäre der Satz: 'Ein guter Beweis, das nicht Alle die Compilermeldungen anschauen' was wiederum banal ist, denn wenn eins im Leben immer gilt, dann, das es kein 'alle' und kein 'immer' gibt.(*)

Wollen wir das mit dem 'beweisen' vielleicht nochmal üben? Und gleich danach, oder besser davor noch, Grundlagen der Logik?

(*) Und der, der mich jetzt auf den Widerspruch hinweist und dabei den Witz nicht kapiert, kriecht'n Keks.

Was aber natürlich stimmt, ist, das man die Warnhinweise des Compilers ernst nehmen und (fast) alles daran setzen sollte, diese auf 0 zu bekommen ohne sie auszuschalten.

PS: Und 'ja', mir ist langweilig

[Sailor]

OT: @himitsu

Und dieses if myboolean = True then ist auch eine geährliche Angelegenheit.

Könntest Du mal aufhören, ständig diesen Unsinn zu posten?

[mkinzler]

Zitat von Sailor:

OT: @himitsu

Und dieses if myboolean = True then ist auch eine geährliche Angelegenheit.

Könntest Du mal aufhören, ständig diesen Unsinn zu posten?

Nein, weil es kein Unsinn ist!

[Uwe Raabe]

Zitat von Sailor:

OT: @himitsu

Und dieses if myboolean = True then ist auch eine geährliche Angelegenheit.

Könntest Du mal aufhören, ständig diesen Unsinn zu posten?

Ich bin mir jetzt nicht sicher, ob du die Aussage oder den Tippfehler meinst. Für ersteren Fall habe ich hier eine kleine Prozedur, die den Unterschied demonstriert:

Delphi-Quellcode:

procedure Main;
var
  myBoolean: Boolean;
  I: Integer;
begin
  I := 2;
  Move(I, myBoolean, Sizeof(myBoolean));
  if myBoolean = (myBoolean = true) then
    Writeln('OK!')
  else
    Writeln('Shit!');
end;

[himitsu]

Wieso hab ich das gepostet?

Hab es "gefährlich" genannt und genug Gründe erwähnt es besser sowas nicht zu machen, was Uwe auch grade nochmal anschaulich demonstriert hat.
(bis auf spezielle Sonderfälle macht man sowas einfach nicht, welche hier nicht vorliegen, wenn man die Funktion reparieren würde)

True ist nunmal nicht als 1 (die Konstante True) deklariert, sondern als <>0, was die automatische Booleanauswertung ordentlich berücksichtigt.

[Sailor]

Wer so was macht, gehört abgemahnt und im Wiederholungsfall gefeuert.
Oder macht Ihr auch das?

Code:

PROCEDURE Main;
 VAR
  myString: String;
         i: Integer;

 BEGIN
  Move('1234',i,4);
  IF i = 1234 
   THEN Writeln('OK!')
   ELSE Writeln('Shit!')
 END;

Man kann mit einem Hammer Nägel in die Wand oder sich auf den Daumen hauen. Ich ziehe ersteres vor. Na ja, war OT und damit Ende Gelände.

[mkinzler]

War ja nur ein Beispiel. Eine weiteres wäre der andere Wert für die Konstante True in der Sprache C, also auch alle Rückgaben von WinAPI Funktionen.

Die Konstante hat in Delphi den Wert 1 in C das binäre Komplement zu False ( 0) nämlich -1!
Und 1 ist was anderes als -1!

als True <> True.

[Sailor]

@Himitsu:
True ist nunmal nicht als 1 (die Konstante True) deklariert, sondern als <>0, was die automatische Booleanauswertung ordentlich berücksichtigt.

Nein, True ist nicht als <> 0 deklariert, sondern in Delphi so implementiert. True ist True und nicht 0 oder 3.5 oder HmstlBmpl. Implementierungsdetails haben in einem Programm nichts zu suchen. Das fällt einem sofort auf die Füße, wenn man z.B. unter Delphi entwickelt und dann auf andere Pascalsysteme portiert. Haben wir jahrelang so gemacht, erfolgreich. Mit obigen Tricks wären wir wohl ziemlich auf die Nase gefallen.

@MKinzler
Wenn ich mich außerhalb meiner Sprache bewege, muß ich eben aufpassen. Lies mal Integerwerte ein, die von einer IBM/360 stammen. In C gibt es im Unterschied zu Pascal keinen Wert True, das ist dort ein
#define true -1.

Aber nu is wirklich gut.