echo-Schreibweise leider suboptimal

[dedlfix]

Hi!

Oftmals wird einfach nur vorhandener Code kopiert, ohne dass sich der Empfänger Gedanken um die Sinnhaftigkeit macht. … Begleittext wird auch nicht immer genau gelesen oder verstanden.
Beispielcode ist Beispielcode. Er soll ein Prinzip verdeutlichen, um den Fragesteller bei seiner konkreten Frage einen Schritt weiter zu bringen. Nicht mehr und nicht weniger. Er soll und kann nicht sämtlichen Qualitätsanforderungen genügen. Er soll nicht skalieren, besonders performant sein oder universell einsetzbar sein.

Ja, das wissen wir als Experten, dass das so ist. Doch der Anfänger weiß das nicht. Der denkt (zu oft), das muss so sein. "or die()" sollte vermutlich immer nur ein Beispiel sein. Und was ist draus geworden? Es wird ständig in Produktivumgebungen eingesetzt und ist dort üblicherweise eine schlechte Vorgehensweise.

Wenn man argumentiert, dass der Begleittext eh nicht gelesen wird, auch nicht explizite Hinweise darauf, dass der Beispielcode nur ein Schema veranschaulicht, nicht produktionsreif ist, dann dürfte man konsequenterweise gar keinen lauffähigen Beispielcode mehr posten – oder nur noch auf High-End-Lösungen verweisen.

Ja, genau das ist meine Argumentationslinie: vorwiegend das Prinzip erklären. Zur Verdeutlichung kann ruhig auch Code dabei sein, gemäß dem Prinzip "ein Bild sagt mehr als tausend Wörter". Aber es sollte kein Gemälde werden und auch keins, das man sich selbst nicht ins Wohnzimmer hängen würde.

Wenn du zudem Code zeigst, der quick'n'dirty ist und erstmal (hoffentlich) funktioniert, jedoch nicht zeigt, wie man es in der Praxis "richtig" macht
Versuche einmal ein Gegenbeispiel, wie man es »richtig« macht. Es wird nicht hinhauen, ohne dass die Umstände und Ziele näher bekannt sind.

Das haut auch bei eine gut gemeinten Code-Lösung nicht hin. Deswegen plädiere ich ja für die Erklärung des Lösungsprinzip, auch wenn diese aufwendiger als aus der Hüfte geschossener Code ist.

Beim den ersten Gehversuchen ist die(mysql_error()) – wie die nicht-objektorientierte, nicht-abstrahierte MySQL-API überhaupt – durchaus angemessen. Du empfiehlst display_errors=on, error_reporting(E_ALL) sowie var_dump. Das fällt in dieselbe Kategorie: schnelles Feedback beim Entwickeln. Im Rahmen einer größeren Webanwendung in der Produktivumgebung nicht angemessen.

or die() mag bei schnellen Test angemessen sein, und dabei verwende selbst ich es. Die Probleminhaber zeigen es jedoch in den meisten Fällen als Teil des für die Produktivumgebung vorgesehenen Codes. Sich alle Fehlermeldungen anzeigen zu lassen empfehle ich üblicherweise immer mit dem Zusatz "während der Entwicklung". Das ist vielleicht recht knapp, doch bin ich nicht immer in der Lage, einen Aufsatz zu dem Thema zu schreiben, zumal das viel zu häufig empfohlen werden muss. error_reporting(E_ALL) und var_dump() sind natürlich keine Fehlerbehandlung für Produktivumgebungen, aber es sind wichtige Hilfsmittel beim Entwickeln, um erst einmal auf Probleme aufmerksam gemacht zu werden.

Du vergleichst mit dem Argument zwei verschiedene Dinge. Letztere sind Debug-Werkzeuge wie alert() und die Fehlerkonsole eines Browsers beim Javascript-Entwickeln. Ihr Einsatzort ist das Labor, um Fehler beim Code-Erstellen auf die Spur zu kommen. Das andere ist Code, der auf Laufzeitbedingungen reagieren soll. Die Debugwerkzeuge verschwinden am Ende wieder, besonders bei var_dump()/alert() ist es ziemlich offensichtlich, dass das im fertigen Code nichts mehr zu suchen hat. Die Laufzeit-Fehlererkennung bleibt im Code und sollte deswegen gleich ordentlich eingebaut werden. Das später nochmal zu ändern, hat im Prinzip zur Folge, dass man alle Funktionstests noch einmal absolvieren muss. Und das muss ja nicht unbedingt sein.

In allen anderen Fällen wäre eine angemessene Fehlerbehandlung zu diskutieren. Auf weitergehende Möglichkeiten hatte Fastix hingewiesen. Um den Umfang eines Postings nicht zu sprengen, kann man eben nur andeuten, dass an dieser Stelle eine bessere Fehlerbehandlung angebracht ist und welche technischen Möglichkeiten zur Verfügung stehen. Wie sie konkret auszusehen hat, lässt sich ohnehin nicht in einem schnellen Beispiel zeigen.

Wenn wir bei dem konkreten Beispiel bleiben, ist es sehr wohl in kurz zu zeigen möglich. Statt

$result=mysql_query($sql) or die(mysql_error() . "<pre>$sql</pre>");

ist es besser es so zu zeigen

if ($result = mysql_query($sql)) {
    // Abfrageergebnisverarbeitung
  } else {
    // Reaktion auf Fehler
  }

Lo!