Fehlermeldungen und Fehlercodes, Konzept? - Seite 2

nikosch · 16.02.2011, 20:21

Zitat:

An unserer Firma sehe ich was passiert wnen eine vernünftige Fehlerbehandlung fehlt und sich auf display_errors verlassen wird. Dem will ich entgegen wirken.

Zitat:

dafür zu sorgen das die Anwendung nicht wegen jedem Furz (Es wurde ein String anstatt eines Integers übergeben - warum auch immer) abbricht

Sorry, das kann ich nicht nachvollziehen. Typverletzungen ergeben eine Notice und noch lange keinen Programmabbruch. Fehler bei Gefahr von Folgefehlern ergeben Warnings. Auch hier läuft alles weiter. Fatal errors werden abgebrochen, weil die Fortführung der Applikation damit nicht möglich ist - eine fehlende Ressource kann man eben auch nicht auslesen.
PHP hat eine sehr sinnvolle Art, Fehler zu behandeln. Das Logfile sagt einem alles, was man braucht (es sei denn, man benötigt den kompletten Aufrufstack) und display_errors hält wirkungsvoll Fehlermeldungen von Besuchern fern.

Chriz · 16.02.2011, 20:30

Es ist sehr problematisch, wenn ein Loggingsystem selbst ein komplexes System ist.
Du weißt nicht welche Fehler auftreten, du kannst unmöglich alle vorhersehen, welche Infos dir vorliegen, etc. Außerdem können kurz- und langfristig riesige Datenmengen entstehen, die man eigentlich nicht mit XML aufblähen will. Der Overhead von XML ist bei dir sicherlich > 50%, vermutlich sehr viel mehr. Diese Datenmengen wollen auch analysiert werden oder zumindest übersichtlich aufbereitet werden. Parse doch mal ein 800 MB XML-Logfile. Ich glaube du hast gute Intentionen, aber einfach zuwenig Erfahrung.

Im Übrigen ist es auch völlig unnötig, denn eine Exception hat eine Message, einen Code, einen Backtrace und du kannst Exceptions auch stacken, also herausfinden welche Exception möglicherweise welche Exception ausgelöst hat. Natürlich kannst du der Exception auch zusätzliche Methoden spendieren. Recht flexibel also. Zugegeben wirds dann auch mit dem Loggen und der Datenmenge schwierig, aber die Information ist da und einfach "stringifizierbar". Wenn man alle Infos haben will, muss man eben mit großen Datenmengen leben.

Zitat:

gleichzeitig dafür zu sorgen das die Anwendung nicht wegen jedem Furz (Es wurde ein String anstatt eines Integers übergeben - warum auch immer) abbricht und der Besucher nur noch weiss sieht mit "Es ist ein Fehler aufgetreten".

Tut sie auch nicht. Aber wenn ein Fehler aufgetreten ist und die Anwendung nicht weiterlaufen kann, geht es den Benutzer nichts an ob das Datenbankpasswort falsch ist oder der Speicher nicht ausreicht. Fehler ist Fehler, relevant ist lediglich ob es weitergehen kann oder nicht. Und das kannst du am Besten mit Exceptions entscheiden.

Abgesehen davon hast du den Error-Reporting Mechanismus nicht so wirklich verstanden oder? Du kannst ihn runterschrauben, ein-/ausblenden und loggen, alles separat. Wenn dein Error-Reporting auf 0 ist, wird auch - bei entsprechender Prüfung - niemals eine ErrorException geworfen. Selbst auf @ kannst du angemessen reagieren (nämlich z.B. garnicht). Insofern ist dein Argument hinfällig.

Ich kann dich nur abschließend vor einem komplexen Logging warnen. Was du draus machst ist dein Senf

Dark Guardian · 16.02.2011, 20:47

Zitat:

Zitat von nikosch

Sorry, das kann ich nicht nachvollziehen. Typverletzungen ergeben eine Notice und noch lange keinen Programmabbruch. Fehler bei Gefahr von Folgefehlern ergeben Warnings. Auch hier läuft alles weiter. Fatal errors werden abgebrochen, weil die Fortführung der Applikation damit nicht möglich ist - eine fehlende Ressource kann man eben auch nicht auslesen.
PHP hat eine sehr sinnvolle Art, Fehler zu behandeln. Das Logfile sagt einem alles, was man braucht (es sei denn, man benötigt den kompletten Aufrufstack) und display_errors hält wirkungsvoll Fehlermeldungen von Besuchern fern.

Zitat:

Zitat von Chriz

Es ist sehr problematisch, wenn ein Loggingsystem selbst ein komplexes System ist.
Du weißt nicht welche Fehler auftreten, du kannst unmöglich alle vorhersehen, welche Infos dir vorliegen, etc. Außerdem können kurz- und langfristig riesige Datenmengen entstehen, die man eigentlich nicht mit XML aufblähen will. Der Overhead von XML ist bei dir sicherlich > 50%, vermutlich sehr viel mehr. Diese Datenmengen wollen auch analysiert werden oder zumindest übersichtlich aufbereitet werden. Parse doch mal ein 800 MB XML-Logfile. Ich glaube du hast gute Intentionen, aber einfach zuwenig Erfahrung.

Im Übrigen ist es auch völlig unnötig, denn eine Exception hat eine Message, einen Code, einen Backtrace und du kannst Exceptions auch stacken, also herausfinden welche Exception möglicherweise welche Exception ausgelöst hat. Natürlich kannst du der Exception auch zusätzliche Methoden spendieren. Recht flexibel also. Zugegeben wirds dann auch mit dem Loggen und der Datenmenge schwierig, aber die Information ist da und einfach "stringifizierbar". Wenn man alle Infos haben will, muss man eben mit großen Datenmengen leben.

Tut sie auch nicht. Aber wenn ein Fehler aufgetreten ist und die Anwendung nicht weiterlaufen kann, geht es den Benutzer nichts an ob das Datenbankpasswort falsch ist oder der Speicher nicht ausreicht. Fehler ist Fehler, relevant ist lediglich ob es weitergehen kann oder nicht. Und das kannst du am Besten mit Exceptions entscheiden.

Abgesehen davon hast du den Error-Reporting Mechanismus nicht so wirklich verstanden oder? Du kannst ihn runterschrauben, ein-/ausblenden und loggen, alles separat. Wenn dein Error-Reporting auf 0 ist, wird auch - bei entsprechender Prüfung - niemals eine ErrorException geworfen. Selbst auf @ kannst du angemessen reagieren (nämlich z.B. garnicht). Insofern ist dein Argument hinfällig.

Ich kann dich nur abschließend vor einem komplexen Logging warnen. Was du draus machst ist dein Senf

Eben weil ich das Verfahren von PHP recht sinnvoll finde versuche ich dies auf meine eigenen Klassen/Methoden/Funktionen anzuwenden und nicht für alles eine Exception zu werfen (wie es wiederholt vorgeschlagen wurde).

Die gezeigte XML Struktur ist auch nicht die Ausgabe des Loggings sondern die Eingabe der Meldungen in das System. Die Ausgabe sieht anders aus.

Und eben auch weil ich nicht alle Fehler vorhersehen kann, also nicht dne ganzen Code mit try ... catch aufblähen möchte nutze ich die Unterteilung in Notices, Warnings und Errors/Exceptions um an gegebener Stelle eine Meldung in angemessener Höhe zu liefern.

Und wirklich komplex ist das System nicht. Besteht bisher aus einer Klasse und einem Ordner zur Ablage der Meldungen und der Logs.

Paul.Schramenko · 17.02.2011, 08:39

Also ich habe für unser System in der Firma mal eine Exception-Handling Klasse geschrieben, die alle geworfenen Exceptions mit Tracestring in die DB schreibt und wenn die mal nicht verfügbar ist, dann eine Email verschickt. Und wenn auch das nicht geht, wird versucht in eine log-Datei zu schreiben. Und im Zend_Framework werden viele Exceptions geworfen

Analog sollte es auch mit set_error_handler gehen.
Sollte das alles nicht funktionieren, na dann shit happens. Also mit der DB sind wir bischer ganz gut gefahren. Mit einem kleinen Webinterface, in dem man die Fehler abarbeiten kann, ist die Sache auch schnell erledigt.

mbunge · 17.02.2011, 09:41

@Paul.Schramenko: Quasi ein Auto-Mantis

, Das wäre eine Idee die ich bei uns auch mal vortragen könnte

Also ich würde dir, genauso wie nikosch, stark empfhelen mit Exceptions / ErrorExceptions zu arbeiten. Da bekommt man eine Detalierte ausgabe mit Trace etc, besser debuggen kann man dann nur noch mit externen Tools (xDebug, etc.).

Im produktiven Einsatz dürften aber keine Fehler mehr auftauchen.

Ich catche Errors mit ErrorException und gebe sie dann an meinen Exceptionhandler weiter. Dann habe ich immer einen zentralen Punkt zum handeln von Errors und Exceptions. Bei Fatal errors greift ErrorException (glaube ich) nicht.

Bei großen Applikationen empfhielt es sich für einzelne Komponenten auch einzelne Exceptions zu verwenden, um auf Komponenten-Fehler möglichst optimal zu reagieren bzw. entsprechende Fehlermeldungen zu erzeugen.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
[Erledigt] Framework Kernel Konzept	Geryon	Software-Design	36	06.10.2010 22:23
Konzept einer Datenbankabstraktion	Dark Guardian	Software-Design	29	30.01.2010 18:13
[Erledigt] Konzept für einen PHP Web Crawler	Dark Guardian	Software-Design	10	23.11.2009 16:31
Konzept für Bowsergame	Wiillli	Beitragsarchiv	1	21.10.2009 15:18
kleines DB Konzept	Tomte	Datenbanken	21	23.08.2008 10:22
Fehlermeldungen	FBI	PHP Tipps 2005-2	12	21.10.2005 16:08
Keine Fehlermeldungen bei Objektzugriff		PHP Tipps 2005-2	1	20.09.2005 12:45
Konzept GFX-Community		PHP Tipps 2005-2	2	22.08.2005 10:22
keine Fehlermeldungen	Michel	PHP Tipps 2005-2	3	18.08.2005 18:11
Fehlermeldungen trotz error_reporting(0)		PHP Tipps 2005-2	9	10.07.2005 16:34
mehr Fehlermeldungen	micbur	PHP Tipps 2005	2	27.05.2005 13:18
Keine Fehlermeldungen	suter	PHP Tipps 2005	2	27.01.2005 09:56
Formular Fehlermeldungen	Mano	PHP Tipps 2005	27	23.01.2005 20:03
Fehlermeldungen mit Switch-Abfrage für $_GET['section']		PHP-Fortgeschrittene	9	22.09.2004 23:59


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

17.02.2011, 08:39
Paul.Schramenko Erfahrener Benutzer Registriert seit: 15.04.2010 Beiträge: 813 PHP-Kenntnisse: Fortgeschritten	Also ich habe für unser System in der Firma mal eine Exception-Handling Klasse geschrieben, die alle geworfenen Exceptions mit Tracestring in die DB schreibt und wenn die mal nicht verfügbar ist, dann eine Email verschickt. Und wenn auch das nicht geht, wird versucht in eine log-Datei zu schreiben. Und im Zend_Framework werden viele Exceptions geworfen Analog sollte es auch mit set_error_handler gehen. Sollte das alles nicht funktionieren, na dann shit happens. Also mit der DB sind wir bischer ganz gut gefahren. Mit einem kleinen Webinterface, in dem man die Fehler abarbeiten kann, ist die Sache auch schnell erledigt. __________________ "My software never has bugs, it just develops random features." "Real programmers don't comment. If it was hard to write, it should be hard to understand!" Positive Bewertungen sind nicht unwillkommen...

17.02.2011, 09:41
mbunge Benutzer Registriert seit: 06.01.2011 Beiträge: 36 PHP-Kenntnisse: Fortgeschritten	@Paul.Schramenko: Quasi ein Auto-Mantis , Das wäre eine Idee die ich bei uns auch mal vortragen könnte Also ich würde dir, genauso wie nikosch, stark empfhelen mit Exceptions / ErrorExceptions zu arbeiten. Da bekommt man eine Detalierte ausgabe mit Trace etc, besser debuggen kann man dann nur noch mit externen Tools (xDebug, etc.). Im produktiven Einsatz dürften aber keine Fehler mehr auftauchen. Ich catche Errors mit ErrorException und gebe sie dann an meinen Exceptionhandler weiter. Dann habe ich immer einen zentralen Punkt zum handeln von Errors und Exceptions. Bei Fatal errors greift ErrorException (glaube ich) nicht. Bei großen Applikationen empfhielt es sich für einzelne Komponenten auch einzelne Exceptions zu verwenden, um auf Komponenten-Fehler möglichst optimal zu reagieren bzw. entsprechende Fehlermeldungen zu erzeugen. Geändert von mbunge (17.02.2011 um 09:52 Uhr).