nicht angemeldet
Halihallo Christian
Hm. Die zweite Version wirft nicht wesentlich mehr Overhead für das
ErrorHandling auf. Was mich daran etwas stört ist
a) das ErrorHandling wird *vor* dem eigentlichen Fehlerverursacher
definiert. Dies halte ich für Verwirrend und unschön. Der
Programmfluss wird "verschleiert" und verschlechtert die
Lesbarkeit des Codes.
d) Eigentlich würde ich sehr gerne auf derartige Perl-spezifische
Konstruktionen verzichten, da sie nicht "universell" und 1:1 in
andere Programmiersprachen umgesetzt werden können. Im Sinne
einer guten Konzeptionierung und leicht portierbaren Lösung hätte
ich eine andere Lösung bevorzugt.
Leider haben alle - mir in den Sinn kommenden - Lösungen den
selben Nachteil: Aufgrund der verwendeten (Primär-)Sprache Perl
bzw. dem "kleinsten gemeinsamen Nenner" vieler Sprachen gibt es
keine allgemein mögliche Lösung mit wenig (Tipp-)Aufwand und guter
Modellierung.
Die Portierung steht für mich zwar überhaupt nicht im Vordergrund,
aber dennoch hätte ich mir eine Lösung gewünscht, welche sich
an "gängiger" Funktionalität und Sprachumfang anlehnt. Aber wie
gesagt: Ich halte dies für fast nicht erfüllbar, man muss Kompromisse
eingehen und Dein Vorschlag halte ich für ein sehr guter Kompromiss.
Viele Grüsse
Philipp