12 Kommentare zu diesem Eintrag
Abonniere dieses Thema via Kommentar RSS oder setzte einen TrackBack URL
mygif_alt
ReMichael sagt, am 3. März 2008 um 17:53:14 Uhr.     

Wenn man nur einmal im Quellcode @ benutzt, wird das sich ja nicht zu sehr auf die Geschwindigkeit auswirken und ist schneller reingeproggt. Aber wenn man mehrere @’s benutzt, sollte man eher auf error_reporting umsteigen ;).

mygif
Miah sagt, am 3. März 2008 um 22:10:05 Uhr.     

warum denn

[php]$error_reporting = error_reporting(E_NONE);

//…

error_reporting($error_reporting);[/php]

und nicht

[php]error_reporting(0);

mysql_connect(’localhost’, ‘root’, ”);[/php]

mygif_alt
Markus sagt, am 3. März 2008 um 22:16:14 Uhr.     

E_NONE ist das gleiche wie 0 ;)
Und ich leg das in eine Variable, damit ich danach wieder den gleichen error_reporting Wert habe wie vorher, denn die Funktion gibt beim Aufruf den vorherigen Wert zurück, und setzt den neuen (sofern gegeben)

mygif
Mister J's sagt, am 4. März 2008 um 16:37:56 Uhr.     

Sollte man in der Entfassung einer Website nicht alle Fehler unterdrücken. Durch das anzeigen von Fehlern könnten doch mögliche Sicherheitslücken enttarnt werden, oder? … und bei Testläufen kann und sollte man sich doch alle Fehler anzeigen lassen.

mygif_alt
ReMichael sagt, am 4. März 2008 um 16:49:15 Uhr.     

Du kannst die Fehler auch ganz unterdrücken und dann in den Logs schauen, was aber etwas länger dauert.

mygif
Markus sagt, am 4. März 2008 um 17:21:22 Uhr.     

Natürlich sollte man es global ausschalten, aber es machen, wie gesagt, zu wenige ;)

mygif_alt
Miah sagt, am 5. März 2008 um 11:55:03 Uhr.     

die möglichkeit den werd wieder zurückzusetzen habe ich garnicht bedacht da ich es eh als sinnlos ansehe den fehler wieder einzuschalten…

logs die täglich gespeichert und in 4 dateien gespeichert werden (je 6 stunden pro tag) ist eh viel übersichtlicher da keinen meiner user meine fehler etwas angehen… sollten manche auch mal drüber nachdenken ^^

mygif
Dominik Jungowski sagt, am 18. November 2008 um 23:53:47 Uhr.     

Wie Mister J schon sagt, sollte man grundsätzlich gar keine Fehler auf der Webseite anzeigen. Und wer zu faul ist Log Files zu lesen, der sollte das mit der IT vielleicht besser gleich bleiben lassen ;-)

Das schlimme am @ Zeichen ist, dass die offizielle PHP Dokumentation an manchen Stellen vorschlägt, es zu verwenden um sinnlose Warnings zu unterdrücken (z.b. beim öffnen von Dateien, die nicht existieren)

mygif_alt
asd sagt, am 30. März 2009 um 11:24:49 Uhr.     

weder error_reporting() noch @ sind saubere lösungen… fehler sollen nicht unterdrückt sondern behandelt werden… siehe:
set_error_handler()
set_exception_handler()
“ErrorException” Klasse

mygif
beNNo sagt, am 31. Juli 2009 um 05:15:06 Uhr.     

ACHTUNG VORSICHT — Sorry, aber hier werden 2 total verschiedene Funktionsweisen miteinander vergleichen.

Das Ergebnis ist wirklich nicht aussagekräftig und einzig der Kommentar von “asd” ist ein vernünftiger Kommentar für einen Programmierer.

So nun aber mal zum Performance Test, der eigentlich keiner ist, da Funktionalitäten verloren gehen.
Man sollte sich vielleicht vorher mal die Funktionsweise von PHPs Errorhandler, error_reporting und ‘@’ anschauen!
http://de2.php.net/manual/de/ref.errorfunc.php

Es wundert mich überhaupt nicht das ‘@’ langsamer ist, denn ‘@’ ist nur ein Synonym für ini_set(’display_errors’, 0); und schaltet nur die php.ini Direktive “display_errors = On” auf “display_errors = Off” für die eine folgende Funktion. Dabei bleibt aber der volle Funktionsumfang des ErrorHandlers vorhanden, wobei error_reporting(0) das ErrorReporting vollständig abschaltet.

Im Klartext bedeutet das: mit ‘@’ eine Fehlerbehandlung noch möglich und mit error_reporting(0) nicht mehr (auch das loggen nicht mehr).
Bsp.: @mail(); -passiert ein Fehler wird dieser bloß nicht angezeigt, aber man könnte ihn z.B. mit dem Errorhandler in einer DB mit Datum/Uhrzeit, Codeline festhalten und analysieren.

MfG beNNo

mygif_alt
beNNo sagt, am 31. Juli 2009 um 05:38:54 Uhr.     

zu den Kommentaren:

Mister J’s sagt:
Sollte man in der Entfassung einer Website nicht alle Fehler unterdrücken…
— sehe ich genauso,so könnten Rückschlüsse gewonnen werden, die so nicht gewollt sind! Unterdrücken, von nicht anzeigen lassen ist hier das Zauberwort! Fehlermeldungen haben einfach in fertigen Websites nichts verloren.

ReMichael sagt:
Du kannst die Fehler auch ganz unterdrücken und dann in den Logs schauen…
— lol wie süss, in welche logs willst du denn schauen, wenn du error_reporting(0) gesetzt hast, etwa in die access.log oder die error.log vom Apache! Unglaublich!!! ;o)

Markus sagt:
Natürlich sollte man es global ausschalten, aber es machen…
— sehe ich auch so, aber dann bitte die php.ini Direktive “display_errors = Off” setzen und NICHT das error_reporting abschlaten.
TIP: ini_set(’display_errors’, 0); nutzen wenn kein Zugriff auf php.ini hat

Dominik Jungowski sagt:
Das schlimme am ‘@’ Zeichen ist, dass die offizielle PHP Dokumentation an manchen Stellen vorschlägt…
— das entspricht NICHT mehr der Wahrheit, die PHP Doku weißt ausdrücklich nicht mehr darauf hin. In deinem Fall is_file, is_readable usw.. Und selbst in dem Standardfall “@mail” (Warring im Safemode) gibt die Doku alternative Lösungen an.
Fazit: Bitte die PHP Doku nicht mit deren Kommentaren verwechseln!

MfG beNNo

mygif
ed sagt, am 15. Februar 2010 um 16:03:57 Uhr.     

Interessant, aber nicht ganz korrekt!

Hinterlasse ein Kommentar

 Name (*Pflichtfeld)

 Email Addresse (*wird nicht veröffentlicht)

 Website (*optional)

Informiere mich wenn hier jemand einen Nachricht hinterlässt.

Bitte beachte: Möglicherweise wird dein Kommentar noch überprüft, du musst ihn also nicht nochmal versenden falls es hier nicht angezeigt wird.