Es stürzt nicht ab. Die Exception wird aufgefangen. Darum kümmert sich jedoch das darunterliegende Framework.
Ah, okay.
die
in Perl wirft also eine Exception, die, wenn sie gefangen wird, nicht zum Programmabsturz führt. Das macht dein Programm für mich aber auch nicht besser verständlich: Wieso wirft die Methodeinit
die Exception und nichtdbh
?
Im Prinzip ist das egal. Z.Z. wird die Ex in dbh() bereits gefangen und per $@ nur durchgereicht. Die Meldung in $@ ist auf jeden Fall für den Anwender verständlich und diese Art von Exceptions sind schließlich Nicht auf fehlerhafte Benutzereingaben zurückzuführen sondern auf Fehler im System (keine Verbindung, DNS kaput, timeout, Daten korrupt usw.)
Zum anderen verlierst du wichtige Kontextinformationen, wenn man einen Fehler nicht an Ort und Stelle behandelt, sondern auf einer niedrigeren Schicht. Auf der niedrigeren Schicht kannst du dann nur noch eine allgemeine Fehlerbehandlung abwickeln.
Da bist Du falsch infomiert. Sobald in Perl eine Ex gefallen ist, steht in $@ die Ursache und wenn man das entspechend einrichtet auch ein Backtrace. Man kann also $@ ohne Informationsverlust auch später befragen nämlich dann wenn der Puffer zurück zum Webserver/User geht.
Dem oder der NutzerIn sollte eine Fehlermeldung zu sehen bekommen, die er bzw. sie verstehen kann.
Kriegen sie auch.
Die ProgrammiererInnen können auch von einem Monitor-Serivce benachrichtigt werden und sich die Fehlermeldungen aus dem Errorlog holen.
Das Errorlog meines FW ist leer: Weil alle Exceptions aufgefangen werden.
Eskalationsprozesse Mail, SMS, .. sind konfigurierbar.
Eine leere Tabelle was denn sonst.
Eine leere Tabelle kann zwei Ursachen haben: Es gibt tatsächlich keine Datensätze oder das Programm ist kaputt. Um den AnwenderInnen klar zu machen, dass ersteres der Fall ist, sollte ihnen auch die entsprechende Information mitgeteilt werden.
Die Anwendung zeigt Statistiken. Wenn bis zum Rendern der Tabelle keine Ex gefallen ist, steht da auch was drin.
Ja, das wäre eine Möglichkeit. Das Problem ist: Dem Code sehe ich nicht an, dass da irgendwas in diese Richtung implementiert ist. Auch hier gilt wieder: Im Zweifelsfall hab ich davon auszugehen, dass das von den ProgrammiererInnen vergessen wurde.
Ich habe das bei meinem ersten Post nicht erwähnt daß sich das FW um die Fehlermeldung kümmert. Weil es gar nicht darum ging sondern um die Frage ob Perlcode schwer lesbar ist. Hier die Zusammenfassung unseres heutigen Meetings
Es ist Sinn und Zweck eines Frameworks, Anwendungen mit gut verständlichen und wenigen Code Zeilen erstellen zu können. Und zwar so, daß man das schon mit ein paar Grundkenntnissen tun und sich dabei auf das Wesentliche konzentrieren kann.
Genau das ist die Kernaussage.
Und Übrigens: Diese Anwendung wickelt fehlerhafte Eingaben über Exceptions ab. Du kannst Dir den ganzen Code anschauen, hier ein Auszug
my $d = Scaliger->new( julidate => $julidate ) or
return $self->errorP( title => "Eingabefehler", descr => "$@");
Ein Backtrace wir da nicht ausgegeben aber das kannst Du ja auch selber testen.
MfG