Perl Beispiel Webanwendung

[1unitedpower]

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 Methode init die Exception und nicht dbh?

Im Prinzip ist das egal. Z.Z. wird die Ex in dbh() bereits gefangen und per $@ nur durchgereicht.

Sieht für mich nach Cargo-Kult-Prgrammierung aus. Wieso eine Exception fangen und nicht behandeln, nur um dann bei jedem Aufruf daran denken zu müssen, eine neue Exception zu schmeißen, damit sie letztendlich von irgendeinem try-catch-Block in deinem Framework gefangen wird und dort nicht behandlet wird?

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.)

Eben, was kümmern die Nutzer die technischen Details?

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.

Der Stacktrace ist eine Momentaufnahme, die nur die Rücksprung-Adressen des Aufruf-Stapels uns einige Meta-Informationen, wie Dateiname, Zeilen- und Spaltennummer enthält. Die Inhalte der Variablen werden aber aus Kapazitätsgründen nicht im Stacktrace gespeichert. Im Stacktrace stehen also nur noch Informationen über den Kontrollfluss, die Zustände des Speichers stehen da nicht drin. Der Stacktrace ist ein Debuggin-Werkzeug: Der Programmierer sieht wo der Fehler aufgetreten ist, aber nicht weshalb ein Fehler aufgetreten ist. Das ist bei der Fehlersuche insofern hilfreich, als das der Programmierer nun weiß, an welcher Stelle er einen Breakpoint setzen muss. Es ist aber in der Regel nicht ausreichend, um zur Laufzeit eine aussagekräfitge Fehlerbehandlung durchzuführen, die sich an den Nutzer richtet: Dafür ist nämich das Warum wichtig und das hängt maßgeblich von den Inhalten der Variablen ab. Deshalb ja die Faustregel: Exceptions immer an Ort und Stelle behandeln, und nicht erst irgendwann später, wo die relevanten Informationen nicht mehr zur Verfügung stehen.

Dem oder der NutzerIn sollte eine Fehlermeldung zu sehen bekommen, die er bzw. sie verstehen kann.

Kriegen sie auch.

Findest du.

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.

Aus dem Auge aus dem Sinn. Exceptions abfangen ist einfach, dazu reicht ein try-catch-Block. Exception-Handling ist aber was anderes.

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.

Vogelstrauß-Prinzip.

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.

Ich bin nach wie vor der Meinung, dass dein Programm wesentliche Aspekte robuster Software-Entwicklung einfach vermissen lässt und deshalb ungeeignet ist, um die Lesbarkeit von Perl zu demonstrieren. Die ständigen Hinweise darauf, dass da unter der Haube irgendwas vielleicht passiert, dass ich dem Code aber nicht entnehmen kann, bekräftigt mich eher in meiner Einschätzung, dass ich den Code überhaupt nicht verstehen kann, ohne die Details deines Frameworks zu kennen.

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.

Eherlich gesagt, bestätigt das so ein wenig meinen Eindruck, dass Usability dir nicht besonders am Herzen liegt. Wenn ich 12/31/2017 eintippe kriege ich eine nichts-sagende Fehlermeldung "Format Datum nach Julianischen Kalender ungültig", das kann ich wohl darauf zurückführen, dass du du <input type="text"> benutzt, wo ein ein <input type="date">" hätte stehen müssen. Ganz davon abgesehen, dass da kein keine <label>`-Elemente am Formular zu finden sind. Du denkst halt, das ist ein Bedienfehler, ich denke das ist ein Bug in deiner Software.