JEDI TJvInterpreterProgram.compile() Exception unter 10.4 Sydney

[schotti65]

Hallo,

folgender Code erzeugt beim Aufruf von TJvInterpreterProgram.compile() eine Exception "internal error":

Code:

unit test1;
procedure test2(Sender : TObject);
begin
try
  // nix
except
  on E: Exception do begin
    // nix
  end;
end;
end;

(Also ironischerweise gerade beim Exception Handling selber, vielleicht ist da auch ein humoriger Entwickler am Werk...)

Wenn man das Exception Handling auskommentiert, geht's:

Code:

unit test1;
procedure test2(Sender : TObject);
begin
try
  // nix
except
  //on E: Exception do begin
    // nix
  // end;
end;
end;

Installiert:
- 10.4 Sydney (+ Patch 1+2)
- Jedi Code Library 3.4 (vom 22.6.20)
- JEDI VCL 3.9

Der obige Code - das erste Beispiel - hat sich seit Jahren nicht geändert und wurde über verschiedene Delphi Versionen (zuletzt 10.3) immer klaglos vom JEDI Interpreter verarbeitet.
Natürlich ist der eigentliche Code viel komplexer, aber ich habe den "internal error" auf das obige Konstrukt zurückführen können.

Irgendwelche Ideen/Lösungsansätze?

[Stevie]

Ich würd ja sagen, da er irrtümlicherweise das E als nen double interpretiert, ist dieser Commit hier schuld: https://github.com/project-jedi/jvcl/pull/115

[schotti65]

Stimmt - liegt tatsächlich and dem "E"!
Folgender Code funktioniert (wieder)

Code:

unit test1;
procedure test2(Sender : TObject);
begin
try
  // nix
except
  on EundIrgendWas: Exception do begin
    // nix
  end;
end;
end;

Da wär ich ja im Leben nicht drauf gekommen - Danke!

[TurboMagic]

Mist! Und wie bekommen wir das so gerade gezogen, dass sowohl die wissenschaftliche Notation als auch der Name E für Exceptions mit dem Interpreter funktionieren?

[Stevie]

Zitat von TurboMagic:

Mist! Und wie bekommen wir das so gerade gezogen, dass sowohl die wissenschaftliche Notation als auch der Name E für Exceptions mit dem Interpreter funktionieren?

Kontext? Außerdem ist wohl nen unmotiviert in der Gegend rumstehendes einsames E kaum eine wissenschaftliche Notation einer Fließkommazahl oder? Mir war so, dass da immer 0-9 vor stehen muss. Und Identifier können nicht mit Zahlen anfangen, also ist das schonmal eindeutig.

Man kann ja auch mal spicken.

[TurboMagic]

Es gibt jetzt einen Pullrequest für einen Fix, der hoffentlich gut genug ist:
https://github.com/project-jedi/jvcl/pull/145

[TurboMagic]

So, nach einer kleinen Korrektur meines Pullrequests Aufgrund des Feedbacks eines Maintainers ist
die Korrektur für die wissenschaftliche Darstellung jetzt drin.

Es ist für wissenschaftliche Darstellung jetzt erforderlich, dass direkt vor dem oder e eine
Ziffer im string ist. Ja, man kann da sicherlich dann weitere Texte generieren die Probleme
verursachen aber die Wahrscheinlichkeit dürfte stark reduziert sein.

[Stevie]

Gut, dass jvcl keine unit tests hat, wa?

[TurboMagic]

Klar wären Unit Tests schön, nur wer fängt die mal an?

Es beteiligen sich ja sowieso nur wenige Leute an dem Projekt!
Die meisten sind ja nur passive Nutzer, deren Beteiligung sich entweder
in Schweigen oder in Kritik ausdrückt. In seltenen Fällen wohl auch in
Bugreports des projekteigenen Mantis, dort aber oft in halbgaren Bugreports,
wodoch gerade Softwareentwickler wissen sollten, was in einen guten Bugreport
alles reingehören sollte!

=> alle Mann (und Frauen) vortreten und mit anpacken!

Ich hab' mir da übrigens nicht viel vorzuwerfen, besonders nach dem ich letztes
Jahr einiges beigetragen habe.

[Stevie]

Zitat von TurboMagic:

Klar wären Unit Tests schön, nur wer fängt die mal an?

Mir persönlich ist das ja egal - hab selbst noch eine ungenügende Testabdeckung in meinen Projekten.

Allerdings kann ich dieses "wer soll das anfangen" einfach so nicht da stehen lassen - denn mit der Argumentation fängt man nie Tests an.
Man baut was ein und anstatt es in nem Button1 Projekt zu testen, schreibt man nen Test - grad wenn's was nicht visuelles ist.

Was das beteiligen an Open Source angeht - das ist son Thema für sich. Gibt leider viele Projekte die nen langsamen Tod sterben (genau wie Delphi selbst, gell? )
Keine Ahnung, wie es anderen geht, aber ich mach mir aber auch eher ungern an ner verwurschtelten und schon länger vor sich hingammelnden Codebasis die Finger schmutzig.
Aber nun wird's arg OT - evtl lohnt es sich, das in nem eigenen Thema aufzugreifen.