Malcolm Beck´s: Fehlerbehandlung in PHP mit MySQL

Beitrag lesen

hi,

Seit wann werden Zeichenkodierungen "geladen"?

Ich wusste nicht, wie man dass sonst nennt, „Aushandeln“ klingt gut, dass werde ich so übernehmen.

» $Error = sprintf('<p>Ein fehler ist beim laden der Zeichenkodierung UTF-8 aufgetreten: <strong>%s</strong></p>', $_connect->error;

Das ist in der Detailgenauigkeit für den Nutzer der Seite uninteressant.

Das stimmt allerdings, da gehe ich wirklich zu sehr ins Detail. Mitloggen und ein kleiner Hinweis für den User ist wohl das Sinnvollste.

Den 500 Internal Server Error halte ich für solche Fälle für durchaus angebracht. Die "Definition" dieses Fehlercodes lautet "[t]he server encountered an unexpected condition which prevented it from fulfilling the request" - und genau das ist ja auch hier der Fall: Der Umstand, dass die Datenbank nicht erreichbar ist, war unerwartet, trat aber jetzt bedauerlicher Weise doch mal ein, shit happens, und hindert den Server daran, die Anfrage des Clients in der gewünschten Form zu bearbeiten.

Auch noch denkbar wäre ein 503 Service Unavailable - "The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay."

Der 503 klingt auch gut, den kann ich ja bei einem Fehler bei DB-Connect oder der Datenbank-Auswahl mit schicken, Fehlerhafte Kodierungsaushandlung oder SELECTs dann mit dem 500er quittieren.
Wobei, jetzt stellt sich mir die Frage, ob eine Fehlerhafte Kodierungsaushandlung überhaupt zustande kommen kann; ich habe das Stück Code aus dem Manual, da dort ein „Eventuell“ auftretender Fehler behandelt wird, dachte ich, dass es schon richtig ist, darauf vorbereitet zu sein.

In deinem obigen Code hast du doch schon die Zuweisung eines Fehlertextes an eine Template-Variable drin stehen - das kann man gut so machen, wenn ein Fehler auftrat, diesen nicht "nackt" ausgeben, sondern durchaus im "normalen" Seitengerüst. (Das Template sollte dann nur auch checken, dass es keine anderen Daten auszugeben hat.)

Genau der von dir in Klammern gesetzte Punkt brachte mich auf diese Frage. Selbst wenn das Template weiss, dass es einige Dinge nicht auszugeben hat, bleiben noch die PHP-Warnungen wie Bspw. „Couldn't fetch mysqli in E:\xa“, die ich höchstens mit „error_reproting(0)“ bzw. „display_errors = OFF“ unterdrücken kann, bleibt nur die frage, ob das Ok ist.
Es wird ja immer darauf plädiert, Fehlerfrei zu programmieren, was aber in diesem Fall ja nicht möglich ist.

"Weiter arbeiten" im gewünschten Sinne (Datenbankeinträge anzeigen, anlegen, ...) kann es natürlich gar nicht - aber das heisst ja nicht, dass es nicht trotzdem *kontrolliert* zu einem "normalen" Ende kommen darf, anstatt mit die() ob all der Schamgefühle Harakiri zu begehen.

Stimmt, eine nichts sagende Weiße Seite mit dem Hinweis „Unknown MySQL server host 'localhos' (11001)“ wird wohl den wenigsten Usern weiter helfen.

mfg

--
echo '<pre>'; var_dump($Malcolm_Beck`s); echo '</pre>';
array(2) {
  ["SELFCODE"]=>
  string(74) "ie:( fl:) br:> va:? ls:? fo:) rl:| n4:# ss:{ de:? js:} ch:? sh:( mo:? zu:("
  ["Meaningful"]=>
  string(?) "Der Sinn des Lebens ist deinem Leben einen Sinn zu geben"
}