Sieht nicht Hausaufgaben aus?
Im Fehlerfall:
Monkey-Debugging bis man was potenzielles findet (den Fehler eingrenzen kann).
Dann genaueres debugging an dieser Stelle und die Fehlerquelle finden.
Entsprechend bereinigen.
Log-Datein / Stack-Traces helfen natürlich immer ungemein!
Im Vorfeld:
Ordentliche Validierungen. Blackbox-Tester suchen!
So richtige DAU sind die Besten.
Du solltest es natürlich auch selber alles durchtesten. Mit der Zeit kennt man ja viele "dumme Aktionen". Erstes Beispiel hierfür: Bitte Alter angeben (18-99): neunzehn
-> NumberFormat Exception und Abbruch. An solchen Stellen ist und bleibt einfach klar, bei einer Typsicheren-Sprache/DB muss ein übernommener Datentyp immer geprüft werden.
White-Box Tests sollten sich eigentlich heut zu Tage im Falle von "Clean Code" "automatisch erledigen".
Bei komplexen Abläufen sollte auch eine ausreichende Planung festgelegt werden.
So kann mit Hilfe von Ablaufdiagrammen (Sequenzd.) Fehler im Vorfeld ausgemerzt werden.
Try Catch ist natürlich wichtig für typischer Weise IO Zugriffe.
Da spart man sich das "File exists" und die Validierung des Inhalts-Typen (Beispielsweise XML erforderlich)
Zur Vorgehensweise der Fehlerbehandlung:
Serverseitig sind wie bereits erwähnt Log-Files sehr wichtig.
Beim typischen Request-/Responselifecycle antwortet man natürlich immer in entsprechenden Format (JSON/XML etc.).
Es bietet sich an, ein Objekt zu erstellen vom Typ "RequestError".
Enthalten sein könnte:
Stack-Trace? (oder nur im "dev"-Modus der Anwendung)
Error-Array mit einzelnen Nachrichten ("Sprachunabhängig" also sowas wie username_required -> für Übersetzungen)
Success: true|false ist eigentlich unnötig. Allerdings in diesem Fall der Übersichthalber und Adaptierbarkeit sinnvoll
RequestTime: Current-Timestamp
uvm. (je nach Gebrauch)
Allerdings kommt in der Webentwicklung noch das HTT-Protokoll zum Einsatz.
Mit Hilfe von Status Codes lässt sich bereits viel realisieren.
Du kannst beispielsweise Status-Codes im 400-er Bereich als Antwort zum Client schicken.
Ungültige Anfrage / Fehlende Daten what-ever: 400 / Bad Request etc.
Da gibt es viele mehr von. Die manchmal auch ausreichen!
Bzw. in einem Fehlerfall ist es sinnvoll einen korrekten HTTP-Status zu übermitteln
Für welchen Fall sind Warnungen angedacht?
In wie weit ändert sich bei jedem 5. Script deine Vorgehensweise?
Man sollte überall korrekt validieren. Beispielsweise ist es für den User beispielsweise nicht gut, wenn die Anwendung "abkackt".. Sollte soetwas mal in Kauf genommen werden, so gibt es aber meist immer noch den Bösewicht, der dir beispielsweise SQL-Injections reinhauen kann.
Und wenn dann beispielsweise Daten geklaut werden oder ähnliches, freut sich der User sicherlich auch nicht mehr.
Ich finde am besten zu Lesen ist:
PHP Code:
<?php
// $dbUserList oder ähnliches eventuell besser als $res?
if ($res !== false && mysql_num_rows($res) > 0) {
// ...
return;
}
// do something
So produziert man nicht unnötig viele Zeilen.
Im Endeffekt ist $res !== false ja nur die Vorbedingung von mysql_num_rows (&&)
Denke es gibt noch viel mehr zum Testen zu sagen aber das wären meine persönlichen Vorgehensweisen sag ich mal
VG
#edit:
Ein Error-Code ist auch immer nicht verkehrt.
Manchmal ist das System komplexer und dann ist es wichtig zu wissen, was genau "gefailed" hat.
Am obigen Coding-Beispiel: Ist $res nun nicht vorhanden also ist etwas mit der Datenbank bzw. dem Query oder kommen einfach keine Daten? Es wäre wahrscheinlich die gleiche Error-Message für den Endanwender. Allerdings anhand des Error-Codes können Entwickler oder Consumer das ganze vereinfachen (für den Endanwender ist es meist egal ob das nun die Datenbank ist oder keine Ergebnisse da sind ... Es sind halt keine Ergebnisse da für den Benutzer, so oder so)
