OOP Parameterübergabe direkt oder indirekt ? (gelöst) - #175079 (Allgemeines zu Perl)

rosti

2014-04-27 21:16

User since
2011-03-19
3470 Artikel
BenutzerIn

2014-04-27T18:46:55 Muffi
Für was ist denn der eval gut?

Das gute alte Exception-Model ;)

eval im Konstruktor vereinfacht die Kontrolle über alles was schiefgehen kann, z.B. das Öffnen einer Datei. Alles, was eine Exception auslösen kann, wird im eval-Block notiert. Wenn Du z.B. in Sachen DBI

Code (perl): (dl )

        DBI->connect_cached(
            "DBI:mysql:$basename:$CFG{$basename}{host}:$CFG{$basename}{port}", 
            $CFG{$basename}{user}, $CFG{$basename}{pass},
            {RaiseError => 1, PrintError => 0}
        );

das Attribute RaiseError = 1 setzt, wird der Verbindungsversuch eine Exception werfen, wenn er fehlschlägt. Setzt Du das in einen eval-Block, werden alle darunterliegenden Anweisungen nicht mehr ausgeführt, das Script sirbt jedoch nicht an dieser Stelle, die Exception wird aufgefangen und die Fehlermeldung steht in $@. So kannst Du an einer anderen Stelle das Script mit einem definierten Zustand sauber beenden.

Modern und anderen PLs entsprechend, gibts auch Perl-Erweiterungen für try/catch-Konstrukte.

Im Beispielfall "Datei": Die Exception wird mit Carp::croak() geworfen. Damit gibts einen Backtrace, der auf die Zeile in der Anwendung zeigt.

Und was noch: eval im Kontruktor ermöglicht

Code (perl): (dl )

my $obj = Class -> new or die $@;

was Du zu vielen CPAN-Modulen findest. Klar, macht ja auch keinen Sinn, ein Script weiterlaufen zu lassen, wenn einen Instanz nicht erstellt werden konnte. Alternative: Das Objekt immer erstellen und hinterher in einer weiteren Zeile fragen, ob alles geklappt hat.

PS/Beispiel: Baust ein Interface was mehrere Methoden definiert. In Klassen, die das Interface implementieren, werden weitere Methoden definiert, die über das Interface laufen und es werden per Factory auch weitere nicht verwandte Klassen eingebunden. Um diesen "Wahnsinn" in den Griff zu kriegen, setze einfach das Interface in den try-Block, fertig ;)

So kann der Entwickler auch selbst mal einen "Dump & die" schmeißen, wenn er sich zwischendurch eine vogelwilde Datenstruktur anschauen möchte ohne dass er sich durch irgendwelche Logfiles schrauben muss.

In meinem Framework http://rolfrost.de/fwarchitektur.html wird somit auch die Response samt HTTP-Headers gepuffert und erst dann ausgegeben, wenn alles gutgegangen ist.
Last edited: 2014-04-27 21:34:14 +0200 (CEST)