Du musst vor dem Benutzen der Daten natürlich diese auch prüfen. Das würde ich mit eigenen Methoden einer eigenen Klasse machen, die dann z.B. auf die Typen prüfen, ob es 0 ist usw.
Wenn du einen Fehler feststellst, musst du das irgendwie loswerden. Du könntest mit try-catch-strukturen zB auch arbeiten.
Ich selber habe immer eine (abstrakte) Klasse Errormessages an Bord, denn für Fehlermeldungen sind einige Dinge wichtig:
- Fehler setzen, ggf. mit Beschreibung
- Fehler speichern
Das Fehler setzen kannst du in der abstrakten Klasse direkt implementieren, da es immer gleich ist. Mit speichern meine ich vorrangig austauschbare Operationen - diese sind also nicht gleich und deshalb nicht in der abstrakten Klasse implementierbar - wie z.B. diese hier:
- Ausgeben
- In eine DB schreiben
- In eine Datei schreiben
- E-Mail schicken
....
Dadurch, dass du deine Unterklassen wie zB ErrorHandlerDB, ErrorHandlerFile oder wie auch immer diese heißen mögen von der Klasse Errormessages ableitest, kannst du sichergehen, dass diese die Operationen setError() usw. unterstützen.
Das schöne für dich ist jetzt, dass du mittels Polymorphie die Objekte einfach austauschen kannst. Du könntest zB eine Fabrik bauen, die dir ein Objekt für die Fehlerbehandlung zurückgibt - und zwar gibt sie dir ein Objekt, das direkt alle Fehler ausgibt, wenn deine Konstante DEBUG auf true steht und ein Objekt, das alles in eine Datei schreibt, wenn die Konstante DEBUG auf false steht.
Welches Objekt du zurück bekommst, hat dich in deinem Code nie zu interessieren.
Wenn du es richtig machst und die Daten vorher gut filterst (Funktionen wie intval oder die ctype Funktionen (wie z.B. ctype_digit) sollten dir da wunderbar helfen), solltest du nicht in die Situation kommen, dass PHP Fehler abwirft, die du nicht fangen kannst.
Und für die Fälle, dass doch, hat man ja auf seinem Produktivsystem auch die Option "display_errors" in der php.ini auf off
Wenn du einen Fehler feststellst, musst du das irgendwie loswerden. Du könntest mit try-catch-strukturen zB auch arbeiten.
Ich selber habe immer eine (abstrakte) Klasse Errormessages an Bord, denn für Fehlermeldungen sind einige Dinge wichtig:
- Fehler setzen, ggf. mit Beschreibung
- Fehler speichern
Das Fehler setzen kannst du in der abstrakten Klasse direkt implementieren, da es immer gleich ist. Mit speichern meine ich vorrangig austauschbare Operationen - diese sind also nicht gleich und deshalb nicht in der abstrakten Klasse implementierbar - wie z.B. diese hier:
- Ausgeben
- In eine DB schreiben
- In eine Datei schreiben
- E-Mail schicken
....
Dadurch, dass du deine Unterklassen wie zB ErrorHandlerDB, ErrorHandlerFile oder wie auch immer diese heißen mögen von der Klasse Errormessages ableitest, kannst du sichergehen, dass diese die Operationen setError() usw. unterstützen.
Das schöne für dich ist jetzt, dass du mittels Polymorphie die Objekte einfach austauschen kannst. Du könntest zB eine Fabrik bauen, die dir ein Objekt für die Fehlerbehandlung zurückgibt - und zwar gibt sie dir ein Objekt, das direkt alle Fehler ausgibt, wenn deine Konstante DEBUG auf true steht und ein Objekt, das alles in eine Datei schreibt, wenn die Konstante DEBUG auf false steht.
Welches Objekt du zurück bekommst, hat dich in deinem Code nie zu interessieren.
Wenn du es richtig machst und die Daten vorher gut filterst (Funktionen wie intval oder die ctype Funktionen (wie z.B. ctype_digit) sollten dir da wunderbar helfen), solltest du nicht in die Situation kommen, dass PHP Fehler abwirft, die du nicht fangen kannst.
Und für die Fälle, dass doch, hat man ja auf seinem Produktivsystem auch die Option "display_errors" in der php.ini auf off
Kommentar