CrabPascal v2.21.0: Native Build ohne Exception-Codegen mehr möglich

CrabPascal bietet seit jeher zwei Ausführungswege: den `run`-Modus mit internem Interpreter sowie den `build-exe`-Modus, der C-Code generiert und diesen nativ kompiliert. Doch während run echte Exception-Handhabung wie in Delphi unterstützt, produzierte der alte Codegen der Build-Pipeline lange Zeit nur Platzhalter – Code, der zwar kompilierte, aber im Betrieb nicht die erwartete Fehlerbehandlung lieferte. Mit Version 2.21.0 (Sprint 13) ändert sich das grundlegend: Der Codegen verzichtet nun auf die Generierung von Exception-Code und verweist Entwickler stattdessen explizit auf den run-Modus.

Warum simulierte Exceptions problematisch waren

In Delphi-Code sieht Exception-Handling typischerweise so aus:

try
  ProcessOrder(OrderId);
except
  on E: Exception do
    LogError(E.Message);
end;

Im Runtime entwirrt der try/except-Block den Call-Stack und prüft die Exception-Typen. Der alte C-Codegen von CrabPascal erzeugte jedoch nur leere Gerüste – ausreichend für die Kompilierung, aber nicht für korrekte Laufzeitarbeit. Noch kritischer: Diese Lücken in der Parität blieben oft unbemerkt. Viele Entwickler gingen davon aus, dass ihre Anwendungen im build-exe-Modus fehlerfrei liefen, bis Produktionsfehler plötzlich anders ausfielen als im run-Modus.

Die Neuerungen in v2.21.0 im Detail

Der Codegen-Modul von CrabPascal lehnt nun die Generierung von C-Code für folgende Konstrukte ab:

• Blöcke mit try / except / finally
• Anweisungen mit raise

Stattdessen wird eine klare Fehlermeldung ausgegeben, die Entwickler direkt zum run-Modus leitet:

crab-pascal build-exe MyApp.dpr
# Fehler: Exception-Handling wird im nativen Codegen noch nicht unterstützt; verwende `crab-pascal run`

Diese transparente Fehlerbehandlung verhindert, dass CI-Pipelines stillschweigend fehlerhaften Code durchlassen. Stattdessen scheitern Builds frühzeitig – und zwar aus dem richtigen Grund.

Wann welcher Modus zum Einsatz kommen sollte

CrabPascal definiert klare Empfehlungen für die Wahl des Ausführungswegs:

• `run`
• Ideal für Entwicklungsarbeit, Horse-APIs, objektorientierte Projekte mit Exception-Handling und schnelle Iterationen.

• `check`
• Unterstützt IDE-Feedback und statische Analysen in CI-Pipelines.

• `build-exe`
• Nur für performancekritische Codebereiche ohne Exception-Logik.

Beispielhaft zeigt das CRUD-Projekt von CrabPascal, wie JSON- und HTTP-basierte Hot Paths problemlos mit build-exe kompiliert werden können – solange keine Exceptions im Spiel sind:

crab-pascal check examples/crud/crud.dpr
crab-pascal run examples/crud/crud.dpr

Regressionstests sichern die neue Policy ab

Im Sprint 13 wurde ein neuer Regressionstest eingeführt: codegen::tests::test_codegen_errors_on_try_raise. Dieser Test stellt sicher, dass der Codegen bei try- oder raise-Konstrukten nicht fälschlich C-Code generiert, sondern stattdessen einen Fehler zurückgibt. Die Testlogik lässt sich wie folgt zusammenfassen:

// Pseudocode: Test prüft, ob Codegen bei try/raise scheitert
assert!(codegen_result.is_err());
assert!(fehlermeldung.contains("use `run`"));

Zukünftige Arbeiten an echter nativem Exception-Handling (etwa über setjmp/longjmp, tabellarische Handler oder LLVM) werden gezielt einzelne Tests grün schalten – ohne dabei die aktuelle, ehrliche Fehlerbehandlung zu untergraben.

Zukunftsperspektiven: Echte native Exceptions

Der aktuelle Schritt ist bewusst konservativ: Mit Version 2.21.0 scheitert der Codegen bei Exception-Konstrukten – statt falsche Sicherheit zu vermitteln. Der nächste Meilenstein besteht darin, Delphi-kompatible Exception-Tabellen direkt im Codegen zu implementieren. Dies erfordert enge Abstimmung mit:

• RTL-Typen in System.SysUtils
• Laufzeit-Layouts für Exception-Objekte

Bis dahin bleibt die klare Dokumentation der Modus-Unterschiede zentral – sei es in diesem Artikel, den Release Notes oder den Hinweisen des check-Commands.

Fazit: Vertrauen statt Scheinlösungen

Für Projekte, die auf strukturiertes Exception-Handling angewiesen sind – und das trifft auf den Großteil von Delphi-Code zu – ist `run` derzeit der einzige unterstützte Weg. Der build-exe-Modus eignet sich ausschließlich für Teile der Sprache, bei denen Parität bereits nachgewiesen ist.

Die Entscheidung von Sprint 13, auf ehrliche Fehlerbehandlung zu setzen statt auf oberflächliche Feature-Checklisten, macht CrabPascal zu einem sichereren Werkzeug für schrittweise Adaption. Entwickler erhalten sofortige Rückmeldung, wo sie ihre Architektur anpassen müssen – und vermeiden so böse Überraschungen in der Produktion.

Bei Fragen steht das Team hinter CrabPascal unter @crabpascal auf Dev.to oder über das Issue-Tracking auf Bitbucket zur Verfügung.