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
? Kommt mir komisch vor. Und daraus ergeben sich direkt zwei weitere Probleme: Zum einen sehe ich dem Ausschnitt nicht an, ob die Exception von einer niedrigeren Programmschicht abgefangen wird und Perl kann AFAIK auch keine Garantie dafür geben. Im Zweifelsfall, habe ich davon auszugehen, dass das vom Programmierer nicht bedacht wurde, also ein Bug ist. 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.
Nutzer bekommen eine Fehlermeldung die der Exception entspricht und die sie genauso wie sie ausgegeben wird an den Programmierer weitergeben können.
Das finde ich aus Usability-Sicht inakzeptabel. Du kannst nicht davon ausgehen, dass deine NutzerInnen wissen, was sie mit einer kryptischen Fehlermeldung anzufangen haben. Selbst wenndu so viel Glück hast sie die Fehlermeldung interpretieren können, wieso glaubst du, sollten sie damit an die ProgrammirerInnen herantreten? Dem oder der NutzerIn sollte eine Fehlermeldung zu sehen bekommen, die er bzw. sie verstehen kann. Die ProgrammiererInnen können auch von einem Monitor-Serivce benachrichtigt werden und sich die Fehlermeldungen aus dem Errorlog holen.
Auch das würde ein Execption werfen die vom FW aufgefangen wird und dem Nutzer eine verständliche Fehlermeldung zeigt.
Wir haben da offenbar unterschiedliche Interpretationen von "verständlich".
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.
Was wenn die Tabelle soviele Datensätze enthält, dass es unzumutbar wäre, sie in einer riesigen Tabelle anzuzeigen?
Das regelt die Query: Limit 30 was ja auch dem Ziel der Anwendung entspricht.
Stimmt, das hab ich übersehen. Der Fall kann also hier nicht eintreten.
Was wenn die Datenbank-Abfrage inakzeptabel lange dauert?
Dann wird mit dem konfigurierten Timeout eine Exception geworfen und das dem Nutzer entsprechend kommuniniziert.
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.
Dein Spielzeugprogramm ignoriert diese Fragestellungen.
Keineswegs. Es mag aussehen wie ein Spielzeug. Kann aber wesentlich mehr und auf jeden Fall all das was Du bemängelt hast.
Selbst wenn es das könnte, wäre der Code für mich immer noch unverständlich, weil die relevanten Informationen dafür nicht aus dem Programmtext ersichtlich sind. Du hast dein Framework selber geschrieben, du weißt was da abgefangen wird und was nicht. Ich lese nur einen Beispielcode und muss mich fragen, was da passiert. Was mir vorenthalten wird, kann ich mir nicht aus dem Ärmel schütteln. Das ist jetzt kein rein Perl-spezfisches Problem, sondern eher ein Problem mit deinem API-Design.
Nun, der gezeigte Code erhebt keinen Anspruch darauf das ganze Framework erklären zu müssen. Das hat der Entwickler im Hinterkopf und das ist mit anderen FW genauso.
Du hast das Framework vielleicht im Hinterkopf, ich nicht. Und ich will auch als Framework-Anwender nicht alle Details im Hinterkopf haben müssen, was, wann, wie, wo angefangen und behandelt wird. Ich will an Ort und Stelle alle relevanten Informationen haben. Irgendwo auf unterster Ebene einen try-catch
-Block zu haben, der alle Fehler abfängt und in generischer Weise darauf reagiert, ist für mich kein gangbarer Weg und endet auch in schlechter UX: Man kann dem oder der AnwenderIn vielleicht noch mitteilen "Irgendwas ist schief gelaufen", eine das ist doch sehr unbefriedigend für alle Beteiligten. Wenn man schon mit Exceptions arbeitet, dann ist es eine gute Faustregel, einen Fehler nie weiter als eine Programmschicht weiter oben (im Stacktrace) zu behandeln. Behandeln kann auch heißen, eine Exception abzufangen, und eine neue aussagekräftigere Exception zu werfen.
Wenn du deinen eigenen Perl-Code gut lesen kannst,
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.
Fehlerbehandlung gehört für mich zum Wesentlichen, aber ich weiß, dass wir da auf keinen grünen Zweig kommen.
Genau das wollte ich hier mal zeigen, nicht mehr und nicht weniger.
Mich hast du damit zumindest nicht überzeugen können.