Notices und Warnungen

[DasGuru]

(bspw. PHP selber, macht das ja im VMS schon jedesmal und das auch noch korrekt ),

nur solange keine Konstante mit diesem Namen definiert wurde.
Und durch irgendwelche Addons kann das ganz schnell passieren.

Sicherlich wäre ein anständiges ErrorManagement vorzuziehen ( mein LCS kann das schon :P )

[DasGuru]

so, das Bugfix ist fertig
Wer möchte kann sich bei mir per PN melden.
Ich denke 50 mio Lose sind angemessen.

Damit sollte das Script auch auf neueren PHP Versionen, ohne Fehler und Warnungen, laufen.

[breaker]

ganz einfach. wenn User das error-reporting anhaben können (was sie sollten) sind Modulersteller "gezwungen" ebenso sauberen Code zu proggen, da sonst ihre Addons fehlermeldungen spucken.

Solange es hier "Entwickler" gibt, die statt "<?php" ein "<=" oder ähnlichen Unfug treiben und sowas auch noch kräftig unter die Leute bringen, wird es immer Meldungen im Code geben, die meisten wissen ja nicht mal, was sie mnit einer "3.Hand"-.Anleitung alles anstellen können und haben absolut keinen Durchblick, was sie da verzapfen

also das Fehlermeldungen im VMS unterdrückt werden ist vom grunde her eher Positive.

einfach ausgegebene Fehlermeldungen können zu einem sicherheitsrisiko werden.
viel sinvoller ist es da die ganzen fehlermeldungen ev. in einer Textdatei/Datenbank zu loggen und dem Admin im Adminforce aufzulisten.

Falsch!
Wenn eine solche Meldung im Script auftaucht, wird sie erkannt und hoffentlich nicht an allen erdenklichen Stellen mit einem @ beseitigt, wenn sowas allerdings Unterdrückt wird, weiss kein Mensch davon,- bis sich jemand damit auseinander setzt, eine Lücke findet und diese Ausnutzt, schon haben wir hunderte gehackte Scripte und keiner weiss so recht, wie es gekommen ist

Notice-Meldungen werden auch dann auftauchen, wenn eine Variable nicht deklariert wurde, so kann ein solcher Code:

$db =& db::init();
$db->query("DELETE FROM " . $db->prefix . "_tabelle WHERE date <> " . $date);

mal "etwas" mehr löschen, weil $date nicht deklariert wurde, ich hoffe, du erkennst den Sinn meines Beitrags

Für mich steht deshalb sauberer Code genauso an 1. Stelle, wie alles andere auch (zb. Kommentare und PHP-Docs)

[Lokutos]

Falsch!
Wenn eine solche Meldung im Script auftaucht, wird sie erkannt und hoffentlich nicht an allen erdenklichen Stellen mit einem @ beseitigt, wenn sowas allerdings Unterdrückt wird, weiss kein Mensch davon,- bis sich jemand damit auseinander setzt, eine Lücke findet und diese Ausnutzt, schon haben wir hunderte gehackte Scripte und keiner weiss so recht, wie es gekommen ist

Hm sehe ich nicht ganz so
ich habe ja nicht gesagt Unterdrücken
nur was ich für falsch halte ist sie genau da auszugeben wo der Fehler passiert. Je nach Konfiguration des Servers z.b. können so Einstellungen etc. mit ausgegeben werden was dann zu Sicherheitslücken / Angriffsflächen führen kann.
das man sie nicht einfach unterdrücken sollte ist klar aber einfach auszugeben ist genauso schlecht.
der ja mein Satz das man sie loggen sollte und im Adminforce anzeigen.
(da sieht sie dan nur der Admin und der wird schon meckern wen da jede sekunde 1000 neue meldungen zukommen.)

[breaker]

Hm sehe ich nicht ganz so
ich habe ja nicht gesagt Unterdrücken
nur was ich für falsch halte ist sie genau da auszugeben wo der Fehler passiert. Je nach Konfiguration des Servers z.b. können so Einstellungen etc. mit ausgegeben werden was dann zu Sicherheitslücken / Angriffsflächen führen kann.
das man sie nicht einfach unterdrücken sollte ist klar aber einfach auszugeben ist genauso schlecht.
der ja mein Satz das man sie loggen sollte und im Adminforce anzeigen.
(da sieht sie dan nur der Admin und der wird schon meckern wen da jede sekunde 1000 neue meldungen zukommen.)

Natürlich solle das ganze über Adminrechte geschaltet werden, so das der Admin auf Wunsch ein Debug-Modus hat (wie in meinem Script)
Normale User oder Gäste sehen von den Meldungen natürlich nichts, bei einem SQL-Error geht das auch über ein gescheiten SQL-Layer, welcher solche Meldungen abfängt