> Da hast Du meinen Artikel nicht richtig gelesen. Doch, jetzt sogar ein zweites Mal, um sicherzugehen dass ich keinen Aspekt übersehen habe, aber die Kritik bleibt bestehen. > Denn ich zeige da sehr wohl die Alternativen auf. Ich habe ja erstmal kritisiert, dass im Beitrag keine nachvollziehbaren Gründe gegen Errorlogging genannt werden. Deine Alternative heißt `RaiseError`, damit teilst du DBI mit, dass bei internen Fehlern Perls `die`-Funktion aufgerufen werden soll und nicht die `warn`-Funktion. Und dann? Wie erfahre ich als EntwicklerIn davon, dass Exceptions im Produktivbetrieb aufgetreten sind? Was ist mit allen übrigen Fehlern, die zur Laufzeit auftreten können, die nicht mit der Datenbank zu tun haben? Und ich halte es auch für keine gute Idee den EndnutzerInnen Perl-Exceptions vor die Füße zu werfen. Im besten Fall ignorieren sie die Meldung nach kurzer Irritation.

> Da hast Du meinen Artikel nicht richtig gelesen. Doch, jetzt sogar ein zweites Mal, um sicherzugehen dass ich keinen Aspekt übersehen habe, aber die Kritik bleibt bestehen. > Denn ich zeige da sehr wohl die Alternativen auf. Ich habe ja erstmal kritisiert, dass im Beitrag keine nachvollziehbaren Gründe gegen Errorlogging genannt werden. Deine Alternative heißt `RaiseError`, damit teilst du DBI mit, dass bei internen Fehlern Perls `die`-Funktion aufgerufen werden soll und nicht die `warn`-Funktion. Und dann? Wie erfahre ich als Entwickler davon, dass Exceptions im Produktivbetrieb aufgetreten sind? Was ist mit allen übrigen Fehlern, die zur Laufzeit auftreten können, die nicht mit der Datenbank zu tun haben? Und ich halte es auch für keine gute Idee, den EndnutzerInnen Perl-Exceptions vor die Füße zu werfen. Im besten Fall ignorieren sie die Meldung nach kurzer Irritation.