wie funktioniert try except

[daNiii]

Hi!
Ich habe ein großes Problem mit try except. Laut meinen Recherchen müsste das Programm versuchen, den Programmcode zwischen try und except durchzulaufen. Ergibt sich in diesem Bereich ein Problem, so überspringt das Programm und läuft nach except weiter.

In meinen Programm aber gibt es Differenzen.
Kann das Programm den Programmcode zwischen try und except nicht durchlaufen, so kommt ein Fehlermeldung!

Delphi-Quellcode:

 try
 Test:= adoquery1.FieldValues['Favoriten'];
    showmessage('Der Track ist bereits bei den Favoriten');

except
   //Test2:= strtoint(Test);
   CD:= cb_cd.text;
      adoquery1.close;
adoquery1.sql.clear;
adoquery1.sql.Add('insert into Favoriten (Favoriten, CD) values("'+favorit+'", "'+CD+'")');
adoquery1.execsql;
favoritenladen();
end;

[Jakob Ullmann]

Wenn eine Fehlermeldung kommt, liegt es wahrscheinlich an deiner Syntax. Try-Except ist für Ausnahmefehler (Exceptions) gedacht... Zum Beispiel Division durch 0 oder sowas (oder StrToInt-Konvertierung). Ist 'Test' deklariert? Passt die Deklaration zum Rückgabetyp von adoquery1.FieldValues[n]?

EDIT: Kopiere bitte mal die Fehlermeldung!

[Jens Hartmann]

Hallo,

ich weiß nicht genau was du mit try/Except vorhast, dies ist wie oben genannt für Fehlerbehandlungen gedacht. Wenn ich deinen Code richtig versteh, willst Du einen Titel zu deiner Favoritendatenbank zufügen, wenn er noch nicht darin steht.

Das solltest Du dann eventuell mit "IF" versuchen.

Gruß Jens

[Jakob Ullmann]

Sorry, hab Fehlermeldung als Compilerfehlermeldung interpretiert. Wenn damit Exception gemeint ist, vergiss bitte, was ich geschrieben habe.

[jaenicke]

Wichtig: Wenn eine Exception kommt, wird diese in Delphi auch innerhalb eines try..except angezeigt. Nur wenn das Programm außerhalb von Delphi ohne Debugger ausgeführt wird oder die Exception in Delphi auf ignorieren gestellt wird, wird die Fehlermeldung von try..except geschluckt und gar nicht angezeigt.

[daNiii]

Danke für eure Antworten.
Ich habe mein Problem jetzt mit IF gelöst.

[Jakob Ullmann]

Zitat:

Zitat von jaenicke

oder die Exception in Delphi auf ignorieren gestellt wird, wird die Fehlermeldung von try..except geschluckt und gar nicht angezeigt.

Letzteres geht mit Tools -> Debugger-Optionen -> Sprach-Exceptions -> Bei Delphi-Exceptions stoppen -> OK (D7). Bei neuen findet man das glaube ich unter der Rubrik "Debugger" bei den Optionen.

[jaenicke]

Zitat:

Zitat von Jakob Ullmann

Bei neuen findet man das glaube ich unter der Rubrik "Debugger" bei den Optionen.

Bei normalen Versionen klickt man einfach bei der Anzeige der Exception an, dass die in Zukunft ignoriert werden soll.
Nur bei sehr alten Versionen wie Delphi 7 oder früher gibts das noch nicht. ;-)

[Jakob Ullmann]

Zitat:

Zitat von jaenicke

Zitat:

Zitat von Jakob Ullmann

Bei neuen findet man das glaube ich unter der Rubrik "Debugger" bei den Optionen.

Bei normalen Versionen klickt man einfach bei der Anzeige der Exception an, dass die in Zukunft ignoriert werden soll.
Nur bei sehr alten Versionen wie Delphi 7 oder früher gibts das noch nicht. ;-)

Wusste ich noch gar nicht. Cooles Feature... :drunken:

[Muetze1]

daNiii: Ich vermute du meinstest das try/finally Sprachmittel und nicht try/except. Ersteres sorgt dafür, dass der Finally Block immer durchlaufen wird, auch im Fehlerfall.

[jaenicke]

Äh, ach ja, da habe ich gar nicht drauf geachtet...

Zitat:

Zitat von daNiii

Ich habe ein großes Problem mit try except. Laut meinen Recherchen müsste das Programm versuchen, den Programmcode zwischen try und except durchzulaufen. Ergibt sich in diesem Bereich ein Problem, so überspringt das Programm und läuft nach except weiter.

Nein, es wird der Code zwischen try und except ausgeführt. Sobald da eine Exception auftaucht, wird zum except gesprungen und der Code zwischen except und end ausgeführt, tritt keine Exception auf, wird der gesamte Code zwischen try und except ausgeführt und dann danach weitergemacht.

Beispiel:

Delphi-Quellcode:

try
  a := a * 5;
  a := a div 0; // Division durch 0
  ShowMessage('Kein Fehler, a = ' + IntToStr(a));
except
  ShowMessage('Fehler');
end;

Es wird nur die Meldung "Fehler" angezeigt, da bei der Exception direkt ins except gesprungen wird und das erste ShowMessage nie erreicht wird.

Heißt: Wenn du Code (wie das erste ShowMessage) nur ausführen kannst, wenn vorher keine Exception aufgetreten ist, gehört das vor das except. Was im Fehlerfalle passieren soll, gehört nach except.

Und wenn du stattdessen etwas immer ausführen willst, egal ob ein Fehler aufgetreten ist oder nicht, dann nimm try..finally und schreib es nach das finally, wie eben Muetze1 geschrieben hat.
Auch da wird direkt zum finally bei einer Exception gesprungen.

[Delphi-Laie]

Ich muß dem Originalposter recht geben. Try-Except scheint irgendwie nicht zu funktionieren. Ich habe das jedenfalls bis heute nicht gerafft, wie das funktionieren soll, und habe auch noch nie selbständig eine solche Befehlssequenz in ein Programm einarbeiten können. Nur mal zwei Beispiele:

Delphi-Quellcode:

var a,b:integer;
begin
b:=0;
  try
  a:=a div b;
  ShowMessage('Kein Fehler')
  except
  ShowMessage('Fehler')
  end
end

ergibt die Meldung "Kein Fehler", also wird der except-Teil nicht angesprungen (obwohl eine Division durch 0 angefordert wird, also in meinen Augen ein völlig absurdes Programmverhalten), bei

Delphi-Quellcode:

var c:real;
begin
  try
  c:=c/0;
  ShowMessage('Kein Fehler')
  except
  ShowMessage('Fehler')
  end
end

wird das Programm mit einem Laufzeitfehler (wohl "heftiger" als eine Exception?) beendet, besser formuliert: abgebrochen.

Fazit: Dieses Sprachkonstrukt ist für mich bis heute (von kopierten Codeschnipseln einmal abgesehen) wertlos.

[jaenicke]

Zitat:

Zitat von Delphi-Laie

Delphi-Quellcode:

var a,b:integer;
begin
b:=0;
  try
  a:=a div b;
  ShowMessage('Kein Fehler')
  except
  ShowMessage('Fehler')
  end
end

ergibt die Meldung "Kein Fehler", also wird der except-Teil nicht angesprungen (obwohl eine Division durch 0 angefordert wird, also in meinen Augen ein völlig absurdes Programmverhalten)

Ja, ist auch klar. Da du a nie benutzt, wird die Zeile schlicht wegoptimiert, die existiert in der Exe nicht mehr. Da sollte aber auch eine entsprechende Compilermeldung kommen, dass das nie benutzt wird...

Und bei deinem zweiten Quelltext sollte wenn, dann nur in Delphi eine Meldung angezeigt werden, aber nicht, wenn das Programm eigenständig läuft oder die Anzeige in Delphi deaktiviert ist.
(Aber eigentlich sollte das auch wegoptimiert werden und nix angezeigt werden von einem Fehler.

[DeddyH]

Stimmt, ein einfaches ShowMessage dazwischen und die Sache stellt sich schon anders dar.

Delphi-Quellcode:

var a,b:integer;
begin
  b := 0;
  try
    a := 1 div b;
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage('Kein Fehler')
  except
    ShowMessage('Fehler')
  end;
end;

[jaenicke]

Zitat:

Zitat von Delphi-Laie

wird das Programm mit einem Laufzeitfehler (wohl "heftiger" als eine Exception?) beendet, besser formuliert: abgebrochen.

Was für eine Delphiversion benutzt du denn? :gruebel:

Also ich habe es gerade einmal ausprobiert. Bei mir wird auch die Zeile in deinem zweiten Beispiel (wie erwartet) wegoptimiert und es kommt die Meldung "Kein Fehler". Hast du noch irgendeine uralte Version oder so? Dann müsste ich das da einmal ausprobieren.

[Delphi-Laie]

Wieder was dazugelernt, vielen Dank!

Wußte gar nicht, daß Delphi derart intelligent mit dem Quelltext umgeht. Klar, die Meldung beim Compilieren kommt.

Nun, nachdem ich die Variable a irgendeiner Verwendung zuführte, kam aber auch keine Exception, sondern das von der Division durch Null bekannte Abbruchverhalten.

Zitat:

Zitat von jaenicke

Und bei deinem zweiten Quelltext sollte wenn, dann nur in Delphi eine Meldung angezeigt werden, aber nicht, wenn das Programm eigenständig läuft oder die Anzeige in Delphi deaktiviert ist.

Tut es aber leider doch, nämlich einfach abzubrechen.

Zitat:

Zitat von jaenicke

(Aber eigentlich sollte das auch wegoptimiert werden und nix angezeigt werden von einem Fehler.

Wiederum: Tut es aber leider doch, nämlich einfach abzubrechen.

Danke für Dein Bemühen, aber try-except hat bei mir leider immer noch die Reputation "unbrauchbar". Schade...

Ich benutze standardmäßig Delphi 3. Kann es sein, daß bei dieser aus heutiger Sicht inzwischen noch recht frühen Delphi-Version das noch nicht richtig implemmentiert wurde? Kann ich mir kaum vorstellen, denn ich habe die fehlerbereinigte, nachgeschonbene 3.01-Version.

Gruß Delphi-Laie

[Apollonius]

Hast du SysUtils eingebunden? Ohne SysUtils gibt es keine Exceptions.

[Delphi-Laie]

Zitat:

Zitat von Apollonius

Hast du SysUtils eingebunden? Ohne SysUtils gibt es keine Exceptions.

Ja, ist auch in Delphi 3 schon standardmäßig, beim Start, für das leere Formular enthalten.

[Hansa]

Das kommt davon, wenn man alles ignoriert und nur guckt, dass es läuft. Egal wie. 8)

Keiner hat das zur Kenntnis genommen :

Zitat:

[Hinweis] Unit1.pas(30): Auf 'a' zugewiesener Wert wird niemals benutzt
[Hinweis] Unit1.pas(28): Auf 'b' zugewiesener Wert wird niemals benutzt

stammt von hier :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;
(*
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage(inttostr(b)+' Kein Fehler')
*)
  except
    ShowMessage('Fehler')
  end;
end;

Leute, die so was permanent ignorieren, denen sollte der Delphi-Compiler besser die Arbeit verweigern, anstatt das selbst auch noch zu ignorieren. :mrgreen: Für Testzwecke ist das vielleicht noch hinzunehmen, irgendwelche überflüssigen Variablen zu haben, aber der Normalfall sollte das nicht sein.

Das hier z.B. wird NICHT compiliert :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;

Zitat:

[Fehler] Unit1.pas(30): Division durch Null
[Fataler Fehler] Project1.dpr(5): Verwendete Unit 'Unit1.pas' kann nicht compiliert werden

Edit :

Zugriff auf a oder b geschieht auch hier nicht :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;
(*
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage(inttostr(a)+' Kein Fehler')
*)
  except
    ShowMessage('Fehler')
  end;
end;

[jaenicke]

Zitat:

Zitat von Delphi-Laie

Ich benutze standardmäßig Delphi 3. Kann es sein, daß bei dieser aus heutiger Sicht inzwischen noch recht frühen Delphi-Version das noch nicht richtig implemmentiert wurde? Kann ich mir kaum vorstellen, denn ich habe die fehlerbereinigte, nachgeschonbene 3.01-Version.

Trotzdem ist Delphi 3 mittlerweile 12 Jahre alt, was erwartest du da?
Da war ja alles noch extrem unkomfortabel, ich frage mich da immer, wieso damit heute noch ernsthaft jemand arbeitet... Masochist? :mrgreen:

[Hansa]

Dass die relevanten Source-Teile identisch waren, das hat auch keiner gemerkt. :mrgreen:

Zitat:

Zitat von Original

Zitat:

Zitat von Hansa

Das kommt davon, wenn man alles ignoriert und nur guckt, dass es läuft. Egal wie. 8)

Keiner hat das zur Kenntnis genommen :

Zitat:

[Hinweis] Unit1.pas(30): Auf 'a' zugewiesener Wert wird niemals benutzt
[Hinweis] Unit1.pas(28): Auf 'b' zugewiesener Wert wird niemals benutzt

stammt von hier :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;
(*
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage(inttostr(b)+' Kein Fehler')
*)
  except
    ShowMessage('Fehler')
  end;
end;

Leute, die so was permanent ignorieren, denen sollte der Delphi-Compiler besser die Arbeit verweigern, anstatt das selbst auch noch zu ignorieren. :mrgreen: Für Testzwecke ist das vielleicht noch hinzunehmen, irgendwelche überflüssigen Variablen zu haben, aber der Normalfall sollte das nicht sein.

Das hier z.B. wird NICHT compiliert :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;

Zitat:

[Fehler] Unit1.pas(30): Division durch Null
[Fataler Fehler] Project1.dpr(5): Verwendete Unit 'Unit1.pas' kann nicht compiliert werden

Edit :

Zugriff auf a oder b geschieht auch hier nicht :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;
(*
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage(inttostr(a)+' Kein Fehler')
*)
  except
    ShowMessage('Fehler')
  end;
end;

KORREKTUR :

Das kommt davon, wenn man alles ignoriert und nur guckt, dass es läuft. Egal wie. 8)

Keiner hat das zur Kenntnis genommen :

Zitat:

[Hinweis] Unit1.pas(30): Auf 'a' zugewiesener Wert wird niemals benutzt
[Hinweis] Unit1.pas(28): Auf 'b' zugewiesener Wert wird niemals benutzt

stammt von hier :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 2; // vorher stand hier :  a := 1 div 0;  
(*
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage(inttostr(b)+' Kein Fehler')
*)
  except
    ShowMessage('Fehler')
  end;
end;

Leute, die so was permanent ignorieren, denen sollte der Delphi-Compiler besser die Arbeit verweigern, anstatt das selbst auch noch zu ignorieren. :mrgreen: Für Testzwecke ist das vielleicht noch hinzunehmen, irgendwelche überflüssigen Variablen zu haben, aber der Normalfall sollte das nicht sein.

Das hier z.B. wird NICHT compiliert :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;

Zitat:

[Fehler] Unit1.pas(30): Division durch Null
[Fataler Fehler] Project1.dpr(5): Verwendete Unit 'Unit1.pas' kann nicht compiliert werden

Edit :

Zugriff auf a oder b geschieht auch hier nicht :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;
(*
    ShowMessage(inttostr(a)); //Hier wird auf a zugegriffen, daher keine Optimierung
    ShowMessage(inttostr(a)+' Kein Fehler')
*)
  except
    ShowMessage('Fehler')
  end;
end;

[DeddyH]

Wie oft willst Du das eigentlich noch posten?

[jaenicke]

Zitat:

Zitat von Hansa

Das hier z.B. wird NICHT compiliert :

Delphi-Quellcode:

procedure TForm1.FormCreate(Sender: TObject);
var a,b:integer;
begin
  b := 0;
  try
    a := 1 div 0;

Doch, in Delphi 3 schon noch glaube ich. Da war die Compilerentwicklung noch nicht so weit, dass der so intelligent war und gemerkt hat, dass da eine Division durch 0 passiert.
Auch viele andere Optimierungen gab es da ja noch nicht, weshalb Programme da teilweise merklich langsamer sind.

[DeddyH]

IIRC ging das noch nicht einmal in Delphi 1.

[jaenicke]

Zitat:

Zitat von DeddyH

IIRC ging das noch nicht einmal in Delphi 1.

Na wenn du das sagst, wirds schon so sein. Ich bin nie auf die Idee gekommen sowas zu schreiben. :mrgreen:
Und zudem nutze ich ja Delphi 3 schon einige Jahre nicht mehr.

[Hansa]

Zitat:

Zitat von DeddyH

IIRC ging das noch nicht einmal in Delphi 1.

DIV 0 wurde wohl nie compiliert. Mein Museum ist noch verfügbar. IMHO neu sind lediglich die Hinweise. Compiler-Verhalten ist gleich geblienen. Beweis : siehe Anhang. :mrgreen:

[DeddyH]

Das wollte ich doch meinen. [ironie] Aber mit den alten Versionen kann man auch nicht arbeiten, ich frage mich, wie wir das früher gemacht haben :zwinker: [/ironie]

[edit] Ironie-Tags hinzugefügt, das ging wohl irgendwie unter *g* [/edit]

[Satty67]

Zitat:

Zitat von DeddyH

IIRC ging das noch nicht einmal in Delphi 1.

Auch nicht bei Borland Pascal 7 (Turbo Pascal 6 sicher auch nicht, aber hab' ich grad nicht installiert)
Compile-Error 62: Division durch 0

€: Ach mist, hansa war schneller... btw. bei mir kommt die Fehlermeldung (in BP7) über der falschen Zeile, nicht in einem Extra kleinen Fenster. Mein BP-7 sieht auch viel moderner aus...

PS: Was Ihr alle gegen den Komfort von Delphi 3-7 habt... ich nutze Delphi 5 und Turbo Explorer 2006. Der Komfort von Delphi 5 reicht dem Hobby-Programmierer locker...

[Hansa]

Du hast ja früher auch von Hand geschrieben und wohl auch programmiert. Heute wird nur noch geklickt, F9 gedrückt bis es geht und dann mit Cut and Paste weitergemacht. Geht immer noch nichts, dann wird notfalls noch hier gefragt. :mrgreen:

@Satty : Frühmerker. :zwinker: Und blauer Bildschirm hat nichts mit modern zu tun. Das da ist Turbo-Analyst. Mit kleinem Sourcecode-Formatter, Profiler etc.

[Satty67]

@Hansa:
Nein, dachte wegen der IDE (Menü und CO), aber wenn es ein anderes Programm war...

So... wird ja tierisch OT hier, gleich gibt es mit dem Rohrstock vom Moderator. Ich muss nicht verwarnt werden, ich geisel mich jetzt selbst etwas und lasse es ab jetzt OT (in diesem Thread) zu posten. :shock: :mrgreen:

[Delphi-Laie]

Jänicke, als Delphi-Guru mit viel Delphi-, Forums-/Foren- und Menschenerfahrung solltest du eigentlich über solcher Häme und Überheblichkeit stehen, auf jeden Fall aber, sie hier abzuladen.

Zitat:

Zitat von jaenicke

Da war ja alles noch extrem unkomfortabel, ich frage mich da immer, wieso damit heute noch ernsthaft jemand arbeitet...

Ich muß mich vor dir nicht rechtfertigen, du sollst aber dennoch eine Antwort bekommen.

Ich kenne alle Delphi-Versionen von 1 bis 7, noch jüngere "modernere" Versionen auszuprobieren, wollte ich mir aus gutem Grunde nicht antun (werden nämlich immer schlimmer, und was ich bisher darüber las, weckte nicht gerade mein Interesse). Trivialität: Vergleiche mal allein die exe-Dateigrößen bei identischen Quelltexten (nebenbei bemerkt: Das ist die einfachste und bequemste (aufwandsärmste) Form, die exe-Dateigröße gering zu halten, nämlich mit der geringstmögliche Delphi-Version zu compilieren, warum hatte das der Autor im Swissdelphicenter übersehen - den Wald vor lauter Bäumen, vor lauter Betriebsblindheit nicht gesehen?).

Es hat schon seinen Grund, daß ich bei Delphi 3 und ggf. (wenn ich ein dynamisches Array verwenden möchte) Delphi 4 benutze. Die "kleinen" Delphi-Compiler sind schnell und stabil und erzeugen kleine(re) exe-Dateien, und deren Sprachumfang reicht mir schon völlig über Gebühr. Ich bin Hobby-/Freizeitprogrammierer und programmiere nur gelegentlich und nur das, was ich privat benötige und mich interessiert. Ich gehöre nicht zu den Freaks, für die jedes neu hinzugekommene Schlüsselwort sofort unentbehrlich ist, kaum haben sie es kennengelernt.

Warum dieser elende try-except-Befehl nicht funktioniert, hattest du (mir) leider auch (bisher?) nicht weiterhelfen können (wenigstens hattest du nicht die Stirn, mir zu kredenzen, daß Delphi 3 es nicht könne, was ich auch kaum glaube). Nicht schlimm, doch dann halte dich bitte auch mit deiner Überhebung mehr zurück.

"Extrem unkomfortabel"? Wenn das die kleinen Delphi-Compiler sein sollen, was war dann Turbo-Pascal mit Mausbedienung? Was dann erst Turbo-Pascal bis Version 5.5 ohne Maus? Oder gar Standard-TP ohne IDE (explizites Linken usw.)? Wie empfindest du dann ein Betriebsprogramm nur mit Befehlszeile? Ich jedenfalls empfinde die Lahmheit größerer, jüngerer Compiler und die redundantischeren Exe-Dateien als unkomfortabel.

Stattdessen verleugnest und verunglimpfst du etwas, was ich vermute, daß es deine eigene Vergangenheit ist, nämlich die Benutzung niedrigerer Delphi-Versionen, mit:

Zitat:

Zitat von jaenicke

Masochist? :mrgreen:

Masochist? Mit schnellen und stabilen Compilern?

[jaenicke]

Zitat:

Zitat von Delphi-Laie

Mit schnellen und stabilen Compilern?

Selbst meine größten Projekte mit ca. 150.000 Zeilen Quelltext kompilieren komplett in ca. 7-8 Sekunden komplett durch mit D2006, schneller ist D3 wohl kaum (auch wenn ich es nicht testen kann, weil ich kein größeres Projekt habe, das da noch laufen würde). Und der erzeugte Code dürfte eher langsamer sein.
Alleine dass in Delphi 3 das Scrollrad der Maus nicht richtig geht und die Codenavigation per Strg + Shift + Pfeil hoch oder die Codevervollständigung, kostet viel Zeit, selbst bei kleineren Dateien...

Zitat:

Zitat von Delphi-Laie

Stattdessen verleugnest und verunglimpfst du etwas, was ich vermute, daß es deine eigene Vergangenheit ist, nämlich die Benutzung niedrigerer Delphi-Versionen mit:

Sicher, ein wenig genervt hat mich die Nutzung schon, aber es gab halt nix besseres zu der Zeit. :mrgreen:

Dass neuere Delphiversionen langsamer starten ist sicher richtig und die Exedateien sind auch größer, aber die paar Sekunden Startzeit (5-7) hab ich dann doch und ob nun 350 oder 600 KiB.
Naja, Hauptsache du kommst damit klar und kannst damit produktiv arbeiten. Ich könnte es im Vergleich zu neueren Versionen definitiv nicht und habe definitiv mit D7 deutlich langsamer gearbeitet als mit D2006.

Aber ist hier nicht das Thema, deshalb breite ich das mal nicht erst noch weiter aus.
Und der Masochist war wie der Smiley schon zeigt natürlich nicht ernst gemeint.

[Delphi-Laie]

Zitat:

Zitat von jaenicke

Naja, Hauptsache du kommst damit klar und kannst damit produktiv arbeiten. Ich könnte es im Vergleich zu neueren Versionen definitiv nicht und habe definitiv mit D7 deutlich langsamer gearbeitet als mit D2006.

Kann ich, sei beruhigt, denn sonst würde ich mir etwas "moderneres" (wieder) installieren. Ohne dynamische Arrays z.B. war ich in Einzelfällen mit D3 am Ende meines Lateins. Ich bin aber noch nie an die Grenzen von D4 gestoßen. Nicht jeder ist Informatiker.

Zitat:

Zitat von jaenicke

Aber ist hier nicht das Thema, deshalb breite ich das mal nicht erst noch weiter aus.
Und der Masochist war wie der Smiley schon zeigt natürlich nicht ernst gemeint.

Gut, dann ist das für mich erledigt, danke! Da ich mal reingeschaut habe und jemand die Nichtfunktion von try-except bemängelte, fühlte ich mich angesprochen, weil ich das auch noch nie zum Laufen brachte.

[DP-Maintenance]

Dieses Thema wurde von "Christian Seehase" von "Programmieren allgemein" nach "Object-Pascal / Delphi-Language" verschoben.
Das ist doch eher delphispezifisch.