Interner Fehler

Fabian W. · Beiträge: 1766 Win 7 D7 PE

Seit neusetem hat Delphi folgende Spinnerei:

Zitat:

[Fataler Fehler] Unit19.pas(63): F2084 Interner Fehler: T2469

Der Fehler liegt hier:

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:

if Combobox1.Text = '' then
  begin
  showmessage('Bitte wählen Sie einen Button aus.');
  break;
  end;
if ListBox1.Items.IndexOf(Combobox1.Text) > -1 then
  begin
  showmessage('Der ausgewählte Button steht schon in der Liste.');
  break;
  end;
ListBox1.Items.Add(Combobox1.Text);

Wenn ich den Codeteil lösche geht es wieder.
Interne Fehle treten laut der Hilfe nur auf, wenn der Code nicht bearbeitet wurde - keine Sysntaxfehler.
Was is aber am Code so ungewöhnlich???

maxk · Verfasst: Mo 25.07.05 15:34

Versuch mal statt Break; Exit; zu verwenden. Break geht glaube ich nur in Schleifen.

Gruß,
maxk

_________________
Ein Computer wird das tun, was Du programmierst - nicht das, was Du willst.

Fabian W. · Beiträge: 1766 Win 7 D7 PE

Oh mann klar. :autsch:

Kneif mich mal einer, aus dem alter sollte ich doch eigentlich raus sein, oder?

Zitat:

Anfängerfehler

mfg

PS: Dsa ist doch aber ein syntaxfehler, warum meldet das der sch... Compiler net?

jasocul · Verfasst: Mo 25.07.05 15:41

Das ist kein Syntax-Fehler. Break kannst du fast überall hinschreiben.

Tastaro · Beiträge: 414 Erhaltene Danke: 23

Warum? Syntaktisch ist alles in schönster Ordnung. Alles richtig geschrieben und auch die Strichpunkte sind alle vorhanden. Demzufolge ist es kein Syntaxfehler.

Aber meiner Meinung nach sollte Delphi bei jedem break und exit mit "Fataler Fehler" abbrechen. DAS wäre mal ne feine Sache. Und wenn man dann schon dabei ist, könnte man das noch auf with ausdehnen.

Beste Grüße
Tastaro

maxk · Verfasst: Mo 25.07.05 16:19

Was hast du gegen Exit? Wenn man es richtig einsetzt, kann man den Quellcode damit sehr vereinfachen. Klar, wenn man es irgendwo in die tiefste Ebene packt, sieht keiner mehr durch, aber am Anfang von Funktionen ist es recht nützlich!

markieren

übersichtlich

1:
2:
3:
4:
5:
6:
7:

function Blub:integer;
begin
 if BlubAlreadyLoaded then Exit;
 if not LoadBlub then Exit;
 if BlubCount=0 then Exit;
 Blubber;
end;

markieren

unübersichtlich

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

function Blub:integer;
begin
 if not BlubAlreadyLoaded then begin
  if LoadBlub then begin
   if BlubCount<>0 then begin
    Blubber;
   end;
  end;
 end;
end;

markieren

gänzlich verwirrend

1:
2:
3:
4:
5:
6:

function Blub:integer;
begin
 if (not BlubAlreadyLoaded) and (LoadBlub) and (BlubCount<>0) then begin
  Blubber;
 end;
end;

Halt ist ebenso sinnvoll, da es die einfachste Möglichkeit ist Exitcodes zu geben (wenn richtig angewandt).

Gruß,
maxk

_________________
Ein Computer wird das tun, was Du programmierst - nicht das, was Du willst.

Tastaro · Beiträge: 414 Erhaltene Danke: 23

Dann füge mal an deine übersichtliche Funktion am Ende nochmal eine Zeile ein, die unabhängig vom Zustand deiner drei Variablem IMMER ausgeführt werden soll.

...

Nun weißt du, warum ich was gegen exit habe. Und genau das Gleiche gilt für break und halt.

Beste Grüße
Tastaro

maxk · Verfasst: Mo 25.07.05 17:27

Klar, aber dies ist meist nicht der Fall. Wenn man es nachträglich machen muss, hat man zusätzliche Arbeit, aber dies passiert (zumindest wenn man vorher plant) selten. Außerdem hat man mit jeder Einrückung weniger Platz für die eigentliche Zeile. Jedenfalls, wenn man so wie ich versucht immer unter 80 Zeichen zu bleiben, damit es sich einfach ausdrucken lässt.
Meine Informatiklehrerin gibt Punktabzug bei der Verwendung von Abbruchbefehlen. Aber ich denke, wenn man sie richtig einsetzt, sind sie eine feine Sache

Gruß,
maxk

_________________
Ein Computer wird das tun, was Du programmierst - nicht das, was Du willst.

Tastaro · Beiträge: 414 Erhaltene Danke: 23

Man kann eine Software nicht planen, wenn diese über Jahre hinweg, abhängig von Kundenwünschen weiterentwickelt wird. Demzufolge ist das Einfügen von Zeilen eine Situation, die sehr häufig vorkommt. Kannste mir ruhig glauben, ich mach das schon ein paar Jahre. :-)

Du kannst Deiner Lehrerin einen leiben Gruß ausrichten: Sie ist eine _sehr_ vernünftige Frau! ;-)

Beste Grüße
Tastaro

maxk · Verfasst: Mo 25.07.05 17:40

Werd ich machen

Natürlich muss eine Software weiterentwickelt werden (logisch!) und natürlich kann mir ein falsches exit dann in die Quere kommen (auch logisch). Aber wenn ich wie oben beschrieben sinnvollere exits nehme, dann kann ich den Code ja auch relativ schnell ändern (danke automatisch Einrückfunktion). Bis dahin kann ich mir aber sehr viel Arbeit sparen.
Ich sehe aber ein, dass exit & Co. den Code unübersichtlicher machen können, vorallem wenn mehrere Programmierer mit unterschiedlichen Codestrategien dran arbeiten.

Gruß,
maxk

_________________
Ein Computer wird das tun, was Du programmierst - nicht das, was Du willst.

BenBE · Verfasst: Mo 25.07.05 17:48

maxk hat folgendes geschrieben:

Was hast du gegen Exit? Wenn man es richtig einsetzt, kann man den Quellcode damit sehr vereinfachen. Klar, wenn man es irgendwo in die tiefste Ebene packt, sieht keiner mehr durch, aber am Anfang von Funktionen ist es recht nützlich!

Exit ist, wenn man den Source übersichtlich hält, an jeder Stelle eine erleichterung.

maxk hat folgendes geschrieben:

markieren

übersichtlich

1:
2:
3:
4:
5:
6:
7:

function Blub:integer;
begin
 if BlubAlreadyLoaded then Exit;
 if not LoadBlub then Exit;
 if BlubCount=0 then Exit;
 Blubber;
end;

maxk hat folgendes geschrieben:

markieren

unübersichtlich

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:

function Blub:integer;
begin
 if not BlubAlreadyLoaded then begin
  if LoadBlub then begin
   if BlubCount<>0 then begin
    Blubber;
   end;
  end;
 end;
end;

Bei mir würden beide Sources das Prädikat "unübersichtlich verdienen. Zwar nicht wegen der Logik, sondern wegen dem Style.

maxk hat folgendes geschrieben:

markieren

gänzlich verwirrend

1:
2:
3:
4:
5:
6:

function Blub:integer;
begin
 if (not BlubAlreadyLoaded) and (LoadBlub) and (BlubCount<>0) then begin
  Blubber;
 end;
end;

Zwar auf den ersten Blick nicht ganz einsichtig, aber sehr kompakt (jedoch nur zu empfehlen, wenn keine Funktions- oder Property-Get-Aufrufe damit verbunden sind.

maxk hat folgendes geschrieben:

Halt ist ebenso sinnvoll, da es die einfachste Möglichkeit ist Exitcodes zu geben (wenn richtig angewandt).

Gruß,
maxk

An der Richtigen Stelle ist Halt immer im Initialization-Abschnitt eines Komponenten-Packages ... Und Delphi ist schneller beendet als mit Datei\Beenden ;-)

Ist kein Scherz! Genau das Problem hatte ich schonmal und daher stehe ich mit dem Halt-Befehl in jeglicher Hinsicht auf Kriegsfuß.
Es gibt IMMER bessere Wege das Programm zu verlassen, als es mit Halt zu Killen. Und seis nur, indem man den lokalen TLS in FS:[0] auf den obersten SEH setzt und ne Exception auslöst ;-)

Aber wenigstens meldet sich Delphi nochmal mit ner Abschiedsmeldung ^^
P.S.: Richtiger wäre in dem Fall: Simple Exception auslösen, korrekte Meldung + Abbruchgrund reinschreiben und dem aufrufenden Programmteil die Möglichkeit zum Beheben geben.

@maxk: Ansonsten gibt mir mal ne Stelle, wo das nicht mehr ausreichend ist!

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

maxk · Verfasst: Mo 25.07.05 18:47

BenBE hat folgendes geschrieben:

Bei mir würden beide Sources das Prädikat "unübersichtlich verdienen. Zwar nicht wegen der Logik, sondern wegen dem Style.

Was gibt es denn an dem Stil auszusetzen? Sag jetzt nicht, dass es das Leerzeichen statt dem Tabulator ist

Oder meinst du das an den Haaren herbeigezogene Blubbern

BenBE hat folgendes geschrieben:

Und seis nur, indem man den lokalen TLS in FS:[0] auf den obersten SEH setzt und ne Exception auslöst ;-)

Ich verstehe nur Bahnhof :oops:

Das meinte ich aber auch nicht zum Thema "halt". Klar, wenn man es falsch einsetzt, dann ist sowas doof, aber z.B. hier:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:

program Gerade;
uses SysUtils;
{$APPTYPE CONSOLE}
begin
 if ParamCount=0 then Exit; // *mrgreen*
 if (IntToStrDef(ParamStr(1),0) mod 2)=0 then Halt(0) else Halt(1);
end.

Jetzt könnte man das Programm in einem Batch benutzen und mittels ERRORLEVEL den Exitcode ermitteln und wüsste, ob die Zahl gerade ist. Bei einer bunten Anwendung mit GUI genauso, nur dass eben das Halt zum Schluss aufgerufen wird. Geht auch mittels ExitCode direkt, aber das ist Geschmackssache...

Gruß,
maxk

_________________
Ein Computer wird das tun, was Du programmierst - nicht das, was Du willst.

Fabian W. · Beiträge: 1766 Win 7 D7 PE

als ich das Projekt neu gelden habe akmm der Fehler:

Zitat:

Break nur in Schleifen

Er erkennt also doch.

BenBE · Verfasst: Di 26.07.05 00:18

maxk hat folgendes geschrieben:

BenBE hat folgendes geschrieben:

Bei mir würden beide Sources das Prädikat "unübersichtlich verdienen. Zwar nicht wegen der Logik, sondern wegen dem Style.

Was gibt es denn an dem Stil auszusetzen? Sag jetzt nicht, dass es das Leerzeichen statt dem Tabulator ist

Oder meinst du das an den Haaren herbeigezogene Blubbern

Ich mag keine Sources, bei denen Einzeilige If's verwendet werden oder das Begin auf der Then-Zeile steht. Deshalb sagte ich Source-Style ;-)

Die Namensgebung bin ich hier im Board schon schlimmeres gewohnt ...

maxk hat folgendes geschrieben:

BenBE hat folgendes geschrieben:

Und seis nur, indem man den lokalen TLS in FS:[0] auf den obersten SEH setzt und ne Exception auslöst ;-)

Ich verstehe nur Bahnhof :oops:

Frag

uall, der erklärt Dir alles bis ins kleinste Detail. Hier nur soviel: Das TLS (= Thread Local Storage) wird über den FS-Selector (Spezielles Segment-Register der CPU) angesprochen und enthält alle nötigen Datenzeiger, die für die Speicherverwaltung des aktuellen Threads notwendig sind. Mit FS:[0] wird der aktuelle SEH (=Structure Exception Handler) angesprochen, der für das verwalten und verarbeiten von Exceptions (AVs, InvalidOps, EResNotFound, ...) zuständig ist. Setzt man diesen auf den äußersten SEH, den man finden kann, so wird im Falle einer Exception nur noch eine Fehlermeldung "Runtime Error 217 at 01234567" angezeigt und das Programm beendet ...

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme