Unterdrückte PHP-Fehler im Logfile und Meldungsfenster

Hallo,

vielleicht eine dumme Frage (wobei dumme Fragen gibt es ja eigentlich nicht :D): War es schon immer so und ist es gewollt, dass mittels @-Operator unterdrückte PHP-Fehler trotzdem ins Logfile und das Meldungsfenster geschrieben werden?

Irgendwie ist mir das jetzt aufgefallen, da eine potenziell auftretende und unterdrückte Warnung, die bisher nicht eingetreten ist, nun auftritt und ich diese dann entsprechend im Log sehe, was - zumindest in dem Fall - eigentlich unnötig ist.

Gruß
Slummi

Eigentlich passiert dies nicht. Hast du mal ein Beispiel?

paresy

Hatte ich neulich auch bei jemand. In einem Modul von mir wurden PHP-Warnungen (zB „array_key_exists“) unterdrückt und von mir selbst „ausgewertet“. Auf keinem meiner IPS-Installationen wurde die Warnung ausgeben - bei einem User erschien die PHP-Warnung aber im Log!
Das war arg seltsam und meine „Lösung“ war am Ende - im Modul umbauen, damit das @ nicht mehr benötigt wird.

Viele Grüße,
Chris

Also ich kann das eigentlich beliebig bei mir reproduzieren.

Aufgefallen ist es mir bei

$variablen_id = @IPS_GetVariableIDByName($value, 12345);

Hier kann es vorkommen, dass $value einen nicht existierenden Namen hat. Deswegen werden potenzielle Warnungen unterdrückt.
Im Skript selbst funktioniert das auch problemlos. Im Log und im Meldungsfenster taucht die Warnung aber (neuerdings?) auf.

Aber es passiert auch bei so banalen Dingen, wie:

$test = @(10 / 0);

Führe ich das Skript manuell aus, wird die Division durch 0 Warnung nicht angezeigt, im Log und im Meldungsfenster taucht sie jedoch auf.

PHP: Fehler-Kontroll-Operatoren - Manual

Wurde ein benutzerdefinierte Fehlerbehandlungsfunktion mit set_error_handler() registriert, dann wird diese immer noch aufgerufen, aber diese benutzerdefinierte Fehlerbehandlung kann (und sollte) error_reporting() aufrufen, das 0 zurückgeben wird, wenn dem Aufruf, der den Fehler auslöste, ein @ vorangestellt war.

Ich kann es mir nur damit erklären. Somit muss du irgendwo einen eigenen Error-Handler nutzen. (z.B. den IPSLogger?)

paresy

Ich nutze aber keinen eigenen Error-Handler. Wüsste zumindest nicht wo.
Habe gerade mal alles nach set_error_handler abgesucht. Keine Treffer. Den IPSLogger nutze ich auch nicht.

Dann würde mir noch noch einfallen, dass irgendein Modul da in Sachen Error-Handler was macht. Aber wie kriege ich das am besten raus? Hatte zunächst das Patami Framework in Verdacht. Das nervt mich schon seit längerem mit irgendwelchen blöden Exceptions (im Fall eines Skript-Fehlers), die gar nichts mit dem Framework zu tun haben. Aber habe da auf die schnelle auch nichts gefunden.

BlindControl habe ich seit ein paar Tagen testweise installiert. Das hat einen Verweis auf den IPSLogger, aber wenn ich die Library nicht habe, dürfte es das ja auch nicht sein.

Hast du eine Idee, wie ich alle Module systematisch prüfen kann?

Das kann ich bestätigen. Seit der 5.1 habe ich das auch. Fehler gehen ins Log obwohl ein @vor dem Code ist.

Gruß,
Peter

Gesendet von iPhone mit Tapatalk

Seht ihr die Fehler auch im Skript-Editor beim Ausführen? Könnt ihr mir mal ein kleines Beispiel geben?

paresy

Nein, wie gesagt, im Skript-Editor werden die Meldungen sauber unterdrückt.

Ich erstelle z.B. ein neues Skript mit dem einzigen (sinnfreien) Inhalt

<?

$test = (10 / 0); 

Führe ich es im Skript-Editor aus, kommt logischerweise

Warning: Division by zero in C:\IP-Symcon\scripts\17323.ips.php on line 3

Im Log und dem Meldungsfenster kommt

08.07.2019, 15:49:55 | PHP Error | Type: E_WARNING
Message: Division by zero
File: C:\IP-Symcon\scripts\17323.ips.php
Line: 3

Ändere ich das Skript nun in

<?

$test = @(10 / 0); 

kommt im Skript-Editor keinerlei Meldung, im Log und Meldungsfenster aber unverändert die Meldung wie oben.

Das kann ich so nicht bestaetigen. Bei

$test = @(10 / 0);

Kommt bei mir weder einen Meldung im Debug noch in der Logdatei.:confused:

Ja, das ist wirklich so. Das klingt sich ähnlich wie die IPSLibrary überall mit ein.
Und da die Fehlermeldungen der Konsole und aus dem Log bei dir auch unterschiedlich sind, würde ich auf das Framework tippen.
Michael

Dann werde ich das Modul mal raus schmeißen. Nutze es im Moment eigentlich eh nicht sinnvoll.

Es kann ja eigentlich nur an irgendeinem Modul liegen, was per autoinclude irgendwas macht. Sonst fällt mir da nichts mehr ein.

Ich berichte mal, ob es an Patami liegt.

Es war wirklich das Patami-Framework.
Nachdem ich zunächst die Option „Das Framework automatisch in allen Skripten laden“ deaktiviert habe, wurden die Fehler schon nicht mehr geloggt. Dafür bekam ich dann „max execution time“ Fehler von Patami. Vielleicht hätte auch die Option „Unbehandelte PHP Fehler und Ausnahmen protokollieren“ zu deaktivieren gereicht. Aber das Framework saß mir ohnehin zu tief in allem drin.

Nachdem ich es dann komplett deinstalliert habe, dabei noch zwei Threads vom Framework hängen geblieben sind, die auch den Shutdown von IPS verhindert haben und nur noch das Killen des Prozesses half, bin ich das Framework nun scheinbar wirklich los und auch die nicht gewollten Logs.

Da muss man auch erst mal drauf kommen, dass es an dem Modul lag.

08.07.2019, 15:49:55 | PHP Error | Type: E_WARNING
Message: Division by zero
File: C:\IP-Symcon\scripts\17323.ips.php
Line: 3

Jupp. Das ist definitiv ein eigener Error Handler. So sehen die „normalen“ PHP Meldungen nämlich nicht aus.

Aber cool, dass du den Verursacher gefunden hat :slight_smile:

paresy

Wo steckt das denn überall drin, bzw. wie kann ich es erkennen? Hab die Situation auch aber k.A. welches Modul das verwendet.

Such mal in allen Scripten und dann zusaetzlich im ModulOrdner nach

set_error_handler