> Kannst Du Dir vorstellen, ein Framework so zu konfigurieren, dass es sämtliche Fehler, einschließlich 404 so abfängt, dass der Webserver gar nichts davon mitbekommt? D.h., es wird gar kein error.log beschrieben, es sei denn, das FW-Script schmiert selbst ab. Du vermengst mit deiner Fragestellung zwei Aufgabenbereiche einer guten Fehlerbehandlung. Zum Einen ist es natürlich wünschenswert, die Fehlerbehandlung gegenüber dem Endnutzer deiner Anwendung so transparent wie möglich zu gestalten. Wenn beispielsweise keine Datenbankverbindung aufgebaut werden kann, kann versucht werden einen Fallback-Server zu kontaktieren. Zum anderen sollte dieser Fehler aber für die Entwickler dokumentiert werden. Ein regelmäßiges Scheitern der Datenbankverbindung deutet auf ein schwerwiegenderes Problem hin, dass nach Möglichkeit untersucht und behoben werden muss. Etwas Ähnliches kann man über die 404-Fehlermeldung sagen, die du bereits angesprochen hast. Hier ist ein transparenter Fallback nur schwer möglich. Wenn eine URL aber regelmäßig in den Error-Logs auftaucht, dann ist das ein Indiz dafür, dass die URL an einer anderen Stelle verlinkt ist, oder dass eine Weiterleitung fehlerhaft konfiguriert ist. Beides bedarf dann einen Entwickler, der die Fehlerursache behebt. Error-Logs sind die Langzeit-EKGs der Software-Entwicklung, sie können auf Symptome hinweisen, die bei einer Sprechstunden-Untersuchung verborgen bleiben.

> Kannst Du Dir vorstellen, ein Framework so zu konfigurieren, dass es sämtliche Fehler, einschließlich 404 so abfängt, dass der Webserver gar nichts davon mitbekommt? D.h., es wird gar kein error.log beschrieben, es sei denn, das FW-Script schmiert selbst ab. Du vermengst mit deiner Fragestellung zwei Aufgabenbereiche einer guten Fehlerbehandlung. Zum Einen ist es natürlich wünschenswert, die Fehlerbehandlung gegenüber dem Endnutzer deiner Anwendung so transparent wie möglich zu gestalten. Wenn beispielsweise keine Datenbankverbindung aufgebaut werden kann, kann versucht werden einen Fallback-Server zu kontaktieren. Zum anderen sollte dieser Fehler aber für die Entwickler dokumentiert werden. Ein regelmäßiges Scheitern der Datenbankverbindung deutet auf ein schwerwiegenderes Problem hin, dass nach Möglichkeit untersucht und behoben werden muss. Etwas Ähnliches kann man über die 404-Fehlermeldung sagen, die du bereits angesprochen hast. Hier ist ein sinnvoller Fallback nur schwer möglich. Wenn eine URL aber regelmäßig in den Error-Logs auftaucht, dann ist das ein Indiz dafür, dass die URL an einer anderen Stelle verlinkt ist, oder dass eine Weiterleitung fehlerhaft konfiguriert ist. Beides bedarf dann einen Entwickler, der die Fehlerursache behebt. Error-Logs sind die Langzeit-EKGs der Software-Entwicklung, sie können auf Symptome hinweisen, die bei einer Sprechstunden-Untersuchung verborgen bleiben.

> Kannst Du Dir vorstellen, ein Framework so zu konfigurieren, dass es sämtliche Fehler, einschließlich 404 so abfängt, dass der Webserver gar nichts davon mitbekommt? D.h., es wird gar kein error.log beschrieben, es sei denn, das FW-Script schmiert selbst ab. Die vermengst mit deiner Fragestellung zwei Aufgaben einer guten Fehlerbehandlung. Zum Einen ist es natürlich wünschenswert, die Fehlerbehandlung gegenüber dem Endnutzer deiner Anwendung so transparent wie möglich zu gestalten. Wenn beispielsweise keine Datenbankverbindung aufgebaut werden kann, kann versucht werden einen Fallback-Server zu kontaktieren. Zum anderen sollte dieser Fehler aber für die Entwickler dokumentiert werden. Ein regelmäßiges Scheitern der Datenbankverbindung deutet auf ein schwerwiegenderes Problem hin, dass nach Möglichkeit untersucht und behoben werden muss. Etwas Ähnliches kann man über die 404-Fehlermeldung sagen, die du bereits angesprochen hast. Hier ist ein sinnvoller Fallback nur schwer möglich. Wenn eine URL aber regelmäßig in den Error-Logs auftaucht, dann ist das ein Indiz dafür, dass die URL an einer anderen Stelle verlinkt ist, oder dass eine Weiterleitung fehlerhaft konfiguriert ist. Beides bedarf dann einen Entwickler, der die Fehlerursache behebt. Error-Logs sind die Langzeit-EKGs der Software-Entwicklung, sie können auf Symptome hinweisen, die bei einer Sprechstunden-Untersuchung verborgen bleiben.

> Kannst Du Dir vorstellen, ein Framework so zu konfigurieren, dass es sämtliche Fehler, einschließlich 404 so abfängt, dass der Webserver gar nichts davon mitbekommt? D.h., es wird gar kein error.log beschrieben, es sei denn, das FW-Script schmiert selbst ab. Die vermengst mit deiner Fragestellung zwei Aufgaben einer guten Fehlerbehandlung. Zum Einen ist es natürlich wünschenswert, die Fehlerbehandlung gegenüber dem Endnutzer deiner Anwendung so transparent wie möglich zu gestalten. Wenn beispielsweise keine Datenbankverbindung aufgebaut werden kann, kann versucht werden einen Fallback-Server zu kontaktieren. Zum anderen sollte dieser Fehler aber für die Entwickler dokumentiert werden. Ein regelmäßiges Scheitern der Datenbankverbindung deutet auf ein schwerwiegenderes Problem hin, dass nach Möglichkeit untersucht und behoben werden muss. Etwas Ähnliches kann man über die 404-Fehlermeldung sagen, die du bereits angesprochen hast. Hier ist ein sinnvoller Fallback nur schwer möglich. Wenn eine URL aber regelmäßig in den Error-Logs auftaucht, dann ist das ein Indiz dafür, dass die URL an einer anderen Stelle verlinkt ist, oder dass eine Weiterleitung fehlerhaft konfiguriert ist. Beides bedarf dann einen Entwickler, der die Fehlerursache behebt. Errorlogs sind die Langzeit-EKGs der Software-Entwicklung, sie können auf Symptome hinweisen, die bei einer Sprechstunden-Untersuchung verborgen bleiben.