nicht angemeldet
Hi,
wenn Beispielsweise die vom Programmierer gewünschte Zeichenkodierung einer Seite nicht geladen werden kann
Seit wann werden Zeichenkodierungen "geladen"?
-- warum auch immer -- sollte die Seite dann trotzdem ausgeliefert werden, eben mit einer falschen Zeichenkodierung, oder sollte man besser an dieser Stelle das Script abbrechen und dem Client eine entsprechende Meldung schicken?
/*
* Zeichenkodierung auf UTF-8 setzen, wenn's nicht klappt, fehler ausgeben
*/
if (!$_connect->set_charset("utf8"))
Ah, OK, du meinst das Aushandeln der Kodierung für die Verbindung zur Datenbank.
Nun, dass das schief geht - nachdem das Herstellen der Verbindung an sich geklappt hat - halte ich für ziemlich unwahrscheinlich. OK, es könnte mal passieren, dass man versucht eine Kodierung auszuhandeln, die die DB gar nicht kennt - aber das dürfte man wohl bereits während der initialen Testphase feststellen. Und dass die Verbindung zum DB-Server in genau dem Augenblick unterbrochen wird oder dieser selber abraucht, kann natürlich theoretisch auch nicht ausgeschlossen werden ...
> ` $Error = sprintf('<p>Ein fehler ist beim laden der Zeichenkodierung UTF-8 aufgetreten: <strong>%s</strong></p>', $_connect->error;`{:.language-php}
Das ist in der Detailgenauigkeit für den Nutzer der Seite uninteressant. Logge es meinetwegen intern für dich irgendwo; aber nach aussen hin reicht es m.E., ein allgemeines Datenbankproblem zu melden, wenn irgendeiner der Schritte DB-Connect, Datenbank-Auswahl oder Kodierungsaushandlung - also alle "initialen" Schritte, die immer stattfinden, bevor man irgendwas von der Datenbank abfragt oder einträgt - schief ging.
> In diesem Zusammenhang würden mich auch die jeweiligen Header-Status interessieren, die da in Frage kommen.
> „Header 200“ und „Header 404“ ist klar, was aber bei den sonstigen Fehlern wie falsche Zeichenkodierung oder Fehler im SELECT-Statement?
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."
Wir gehen ja schliesslich davon aus, dass bei unserem GuterHoster™ das Abrauchen der Datenbank nicht auf lange Sicht unbemerkt bleibt, sondern dass die Systeme schön ge-monitored werden, und sich deshalb alsbald ein Service-Wiesel höchst fleissig darum kümmern wird, dem unerfreulichen Zustand Abhilfe zu schaffen - also können wir dem Client auch mitteilen, dass wir (der Server) uns mal kurz unpässlich fühlen, aber hoffen dass wir nach einem kleinen Kräuterteechen gleich wieder auf dem Damm sind, um hübsch Konversation machen zu können.
> Was tun, wenn die Verbindung zur Datenbank nicht aufgebaut werden kann? Gibt es Alternativen zu `die()`{:.language-php}?
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.)
> Wobei dann noch zu klären wäre, warum das Script weiter arbeiten sollte, wenn eh keine Verbindung hergestellt werden kann.
"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.
MfG ChrisB
--
Light travels faster than sound - that's why most people appear bright until you hear them speak.