Fehlerbehandlung

Morgen werte Herren & Damen,

ich hab mal ein paar Fragen bez�glich Fehlerbehandlung.

Gebiete: Funktionen, Restlicher Code (Klassen sind zur Zeit nicht wichtig)
Wie geht ihr vor?
Macht ihr um Funktionen ein Try-Catch Block oder gibt ihr bei Fehlermeldung ein Array zur�ck mit 2 Werten (Status false & Fehlermeldung)?

Wie geht ihr vor bei der Auswertung von Bsp.: GET & POST vor?
Alle Fehlermeldung in einem Array ausgeben und zum Schluss ausgeben?

Ich selber verwende dabei 3 Array.
Success, Warning und Error
Diese werden dann je nach Fehler bef�llt und zum Schluss eines "Blockes" ausgegeben. Wenn die Error Variable gef�llt ist dann wird das Script auch gleich beendet. Wiederholt sich dann einige Male z.B. nach GET & POST Auswertung nach Datenschreiben nach Datenselektierung ...

Wenn mir wer dabei gute Tipps (auch welche die ich nicht erw�hnt habe) geben kann w�r ich erfreut.

Mit freundlichen Gr��en

Kroko

#edit
Schreibe gef�hlt in jedem 5 Script meine Fehlerbehandlung anders..

#edit2
Was mir grad noch einf�llt bei einer MySQL abfrage welche Variante ist leserlich besser?

PHP Code:


			
if ( $res !== false ) {

    if ( mysql_num_rows($res) > 0 ) {

        // Mach was

    }

    else {

        // Fehler

    }

}

else {

    // Fehler

}



// oder



if ( $res === false ) {

    // Fehler

}

if ( mysql_num_rows == 0 ) {

    // Fehler

}



// Mach was

Sieht nicht Hausaufgaben aus? :D

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)