Toni: nichta alle fehler trotz error_reporting(E_ALL)

Ich habe während dem entwickeln immer auf error_reporting(E_ALL) gestellt und ja, display_errors is on.

Ich verwende WAMP lokal, daher volle Kontrolle.

Leider kriege ich manchmal nur eine weiße Seite. Dann zum Beispiel, wenn ich eine Funktion aufrufe, die es nicht gibt (Tippfehler).

Bsp: $a = stripslahes("sowienochstring");

Irgendeine Idee, wie ich die reporten kann? Oder geht das generell nicht?

Liebe Grüße

  1. Hello,

    Ich habe während dem entwickeln immer auf error_reporting(E_ALL) gestellt und ja, display_errors is on.

    Ich verwende WAMP lokal, daher volle Kontrolle.

    Welche Version?
    Hast Du an der php.ini Änderungen vorgenommen oder in Virtual Hosts, .htaccess oder sonstigen Möglichkeiten Änderungen an der Konfiguration vorgenommen?

    Hast Du auch die Einstellung "display_startup_errors" berücksichtigt?

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
     ☻_
    /▌
    / \ Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
  2. Hallo,

    Ich habe während dem entwickeln immer auf error_reporting(E_ALL) gestellt und ja, display_errors is on.

    das ist gut, aber damit deckst du nicht alles ab. Vor allem: Wie setzt du diese beiden Einstellungen? Innerhalb des Scripts, oder schon in der php.ini? Wenn du sie erst im Script setzt, ist es kein Wunder, dass sie bei Parse Errors und ähnlichem nicht wirken.

    Leider kriege ich manchmal nur eine weiße Seite. Dann zum Beispiel, wenn ich eine Funktion aufrufe, die es nicht gibt (Tippfehler).

    Ja. Dann scheitert der PHP-Parser schon daran, dein Script überhaupt intern zu übersetzen, zu interpretieren. Dann ist die Anweisung error_reporting(...) sch***egal, weil weil sie nie zum Zuge kommt. Dein Script wird nicht einmal gestartet.

    Irgendeine Idee, wie ich die reporten kann? Oder geht das generell nicht?

    Setze error_reporting und display_errors direkt über die php.ini, nicht im Script. Hat einen weiteren Vorteil: Wenn du die Scripte vom Testserver in die endgültige Umgebung kopierst, brauchst du sie nicht nochmal anzufassen.

    Ciao,
     Martin

    --
    Der geistige Horizont ist der Abstand zwischen Brett und Hirn.
    Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
    1. Hi!

      Ich habe während dem entwickeln immer auf error_reporting(E_ALL) gestellt und ja, display_errors is on.
      das ist gut, aber damit deckst du nicht alles ab.

      Um es mal zu präzisieren: Abgesehen von den schon erwähnten Fehlern, die auftreten, bevor PHP die Chance hat, diese Funktion im Scriptablauf auszuführen, deckt das E_ALL wirklich nicht alles ab. E_STRICT ist davon ausgenommen, jedoch handelt es sich dabei nur um Hinweise, wenn man vorwiegend objektorientierten PHP4-Code nicht richtig nach PHP5 umgeschrieben hat. Das ist also meist nichts Tragisches, was einen da verborgen bleibt.

      Leider kriege ich manchmal nur eine weiße Seite. Dann zum Beispiel, wenn ich eine Funktion aufrufe, die es nicht gibt (Tippfehler).
      Ja. Dann scheitert der PHP-Parser schon daran, dein Script überhaupt intern zu übersetzen, zu interpretieren. Dann ist die Anweisung error_reporting(...) sch***egal, weil weil sie nie zum Zuge kommt. Dein Script wird nicht einmal gestartet.

      Nein. Nicht vorhandene Funktionsaufrufe lassen den Parser nicht scheitern, denn die Funktionsdeklaration kann ja auch erst im Laufe des Betriebes hinzugeladen werden. Es sind vermutlich formale Syntaxfehler, wie vergessene Zeichen. Für die ist übrigens auch nicht display_startup_errors zuständig sondern auch "nur" display_errors.

      Wenn display_errors auf off steht, sind davon auch nur die Syntaxfehler des Startscripts betroffen. Alle Syntaxfehler der inkludierten (nebst requireten) Scripte werden wieder angezeigt, wenn vor deren Aufruf das display_errors eingeschaltet wird.

      Irgendeine Idee, wie ich die reporten kann? Oder geht das generell nicht?
      Setze error_reporting und display_errors direkt über die php.ini, nicht im Script.

      Oder die anderen Möglichkeiten wie .htaccess für die Modulvariante oder .user.ini für CGI ab PHP 5.3

      Hat einen weiteren Vorteil: Wenn du die Scripte vom Testserver in die endgültige Umgebung kopierst, brauchst du sie nicht nochmal anzufassen.

      Man köönte auch vor dem Im-Script-Setzen den Servernamen auswerten. Oder man setzt es nur an einer einzigen aber zentralen Stelle.

      Lo!

      1. Hallo,

        Leider kriege ich manchmal nur eine weiße Seite. Dann zum Beispiel, wenn ich eine Funktion aufrufe, die es nicht gibt (Tippfehler).
        Ja. Dann scheitert der PHP-Parser schon daran, dein Script überhaupt intern zu übersetzen, zu interpretieren. Dann ist die Anweisung error_reporting(...) sch***egal, weil weil sie nie zum Zuge kommt. Dein Script wird nicht einmal gestartet.
        Nein. Nicht vorhandene Funktionsaufrufe lassen den Parser nicht scheitern, denn die Funktionsdeklaration kann ja auch erst im Laufe des Betriebes hinzugeladen werden.

        stimmt, fehlende Funktionen (etwa wegen Tippfehlern) fallen erst auf, wenn die Funktion tatsächlich aufgerufen wird. Danke für die Richtigstellung.

        Es sind vermutlich formale Syntaxfehler, wie vergessene Zeichen.

        Ja. Fehler, die einem als Programmierer immer mal wieder passieren.

        Wenn display_errors auf off steht, sind davon auch nur die Syntaxfehler des Startscripts betroffen. Alle Syntaxfehler der inkludierten (nebst requireten) Scripte werden wieder angezeigt, wenn vor deren Aufruf das display_errors eingeschaltet wird.

        Irgendwie logisch ...

        Hat einen weiteren Vorteil: Wenn du die Scripte vom Testserver in die endgültige Umgebung kopierst, brauchst du sie nicht nochmal anzufassen.
        Man köönte auch vor dem Im-Script-Setzen den Servernamen auswerten. Oder man setzt es nur an einer einzigen aber zentralen Stelle.

        Klar, kann man auch. Ich wollte nur auf die IMO praktische Möglichkeit hinweisen, die besonderen Bedingungen für das Testsystem (z.B. Error Reporting) über die Konfiguration eben dieser Testumgebung abzuhandeln, und nicht im Script selbst.

        Ciao,
         Martin

        --
        Wer im Glashaus sitzt, sollte Spaß am Fensterputzen haben.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      2. Also, in der php.ini stehen bereits alle Werte auf maximale Anzeige :)

        display_errors = ON
        display_startup_errors = ON
        error_reporting = E_ALL

        Wie gesagt ist es wirklich schon bei vertippten Funktionsnamen. KEINE SYNTAX FEHLER wie vergessenes Semikolon.

        $string = strip_tags($string);

        alles super, dann bei

        $string = stip_tags($string);

        weiße Seite und ich finde den Fehler (manchmal) schwer. Das nervt etwas. Was ist da los?

        Bitte weitere Tipps geben. Das muss doch behebbar sein?!

        Liebe Grüße und vielen Dank.

        1. Hi,

          Also, in der php.ini stehen bereits alle Werte auf maximale Anzeige :)

          Ist das auch die *richtige* php.ini?

          phpinfo() zeigt dir oben an, welche verwendet wird.
          Und auch die einzelnen Optionen kannst du dort kontrollieren, ob sie tatsächlich die Werte haben, die du annimmst.

          MfG ChrisB

          --
          RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?
          1. phpinfo() zeigt dir oben an, welche verwendet wird.
            Und auch die einzelnen Optionen kannst du dort kontrollieren, ob sie tatsächlich die Werte haben, die du annimmst.

            ist die richtige php.ini

              
            echo "vor dem Funktionsaufruf";  
            $a = stip_tags("hisdkfj");  
            die("nach dem Funktionsaufruf");  
            
            

            gibt mir "vor dem Funktionsaufruf".

            1. Hi!

              echo "vor dem Funktionsaufruf";

              $a = stip_tags("hisdkfj");
              die("nach dem Funktionsaufruf");

              
              > gibt mir "vor dem Funktionsaufruf".  
                
              Wenn du an der Stelle nochmal in die phpinfo() schaust, sind die relevanten Werte immer noch richtig gesetzt?  
                
                
              Lo!
              
              1. Wenn du an der Stelle nochmal in die phpinfo() schaust, sind die relevanten Werte immer noch richtig gesetzt?

                Schönen Dank. Du hast was entdeckt :)

                An dieser Stelle gibts bei error_reporting ne glatte 0, wo es oben im script noch 30719 gibt.

                Jetzt die Frage, wer stellt mir das um? Werde es mal sukzessive im Script einbauen.....

                Mhhh. Das wusste ich wohl nicht von den ini-Einstellungen. Sobald ich in besagtem Script bin, steht der Wert auf 0. Das Script wird included.

                In der Hauptdatei ist es noch gut.
                So, wie ich es jetzt gerade sehe, ist es weg, sobald ich im Script bin.

                Finde ich ja komisch. Es handelt sich dabei wohl um alle Werte der php-ini. oder? Soll ich die jetzt alle nachbilden oder gibts da was?

                VIELEN DANK FÜR DIE IDEE.

                1. Hi!

                  An dieser Stelle gibts bei error_reporting ne glatte 0, wo es oben im script noch 30719 gibt.
                  Jetzt die Frage, wer stellt mir das um? Werde es mal sukzessive im Script einbauen.....

                  Das kann auch ein @ vor einem der Elemente in deinem Aufrufstack sein.

                  Es handelt sich dabei wohl um alle Werte der php-ini. oder?

                  Es sind die aktuell gesetzen Werte. Die können aus verschiedenen Quellen kommen und auch im Script noch umgestellt werden.

                  Soll ich die jetzt alle nachbilden oder gibts da was?

                  Sicherstellen, dass es kein Programmteil deaktiviert, könnte schon reichen.

                  Lo!

                  1. Das kann auch ein @ vor einem der Elemente in deinem Aufrufstack sein.

                    dedlfix, Du bist ein Halbgott!!!

                    Das war der Tipp. Ich habe die Inkludierung mit @include gemacht. Habe das nicht erwähnt, weil ich die Konsequenzen nur so abgeschätzt habe, das es keine Warnungen zeigt, wenn die Datei nicht vorhanden ist. Wußte nicht, dass es auch alle Warnungen durch dieses Script unterdrückt. Vielen Dank für diesen Wissenzuwachs!

                    Hab jetzt ein kleines if(file_exists()) davorgesetzt und nun werden alle fehler angezeigt, wie ich es möchte.

                    Vielen DAnk

                    1. Hi!

                      Ich habe die Inkludierung mit @include gemacht. Habe das nicht erwähnt, weil ich die Konsequenzen nur so abgeschätzt habe, das es keine Warnungen zeigt, wenn die Datei nicht vorhanden ist. Wußte nicht, dass es auch alle Warnungen durch dieses Script unterdrückt.

                      Macht es auch nicht, sondern nur die, die durch den Inklude-Prozess entstehen, inklusive dem Code, der direkt ausgeführt wird. Wenn also Funktionen darin definiert sind, sind davon nur die Syntaxfehler betroffen. Die Fehler bei späteren Aufrufe interessieren sich nicht mehr für das @.

                      Lo!

        2. Hi!

          weiße Seite und ich finde den Fehler (manchmal) schwer. Das nervt etwas. Was ist da los?

          Frag nicht uns, wir können nicht hellsehen.

          Bitte weitere Tipps geben. Das muss doch behebbar sein?!

          Nimm die() mit irgendeinem Text als Argument (keine Zahl, die wird nicht ausgegeben) und setz ihn immer weiter nach hinten im Scriptablauf. Wenn die Ausgabe nicht mehr erfolgt, liegt der Fehler zwischen der jetzigen und vorherigen Position.

          Lo!

        3. Yerf!

          weiße Seite und ich finde den Fehler (manchmal) schwer. Das nervt etwas. Was ist da los?

          Mal eine ganz banale Idee: schon mal im Browser in den Quelltext der Seite geschaut? Evtl. wird die Meldung wegen einer verhunzten HTML-Struktur nicht angezeigt.

          Gruß,

          Harlequin

          --
          RIP --- XHTML 2
          nur die Besten sterben jung
          1. Mal eine ganz banale Idee: schon mal im Browser in den Quelltext der Seite geschaut? Evtl. wird die Meldung wegen einer verhunzten HTML-Struktur nicht angezeigt.

            Gute Idee, aber leider nein. Da auch nix.

  3. Hi,

    Leider kriege ich manchmal nur eine weiße Seite. Dann zum Beispiel, wenn ich eine Funktion aufrufe, die es nicht gibt (Tippfehler).
    Irgendeine Idee, wie ich die reporten kann? Oder geht das generell nicht?

    Ich würde dir empfehlen, auf die Anzeige von Fehlern im Browser komplett zu verzichten und stattdessen einfach mit "tail" oder einem ähnlichen Programm (am Besten mit "follow"-Funktion wie "tail -f" der Logdatei zu lauschen.

    Dies hat mehrere Vorteile:
    a) du nutzt das gleiche "Debugging" auf Produktionsumgebungen (wo display_errors meist auf off steht) wie in der Entwicklungumgebung
    b) Fehlermeldungen stören nicht automatisch den Datenfluss (was insbesondere relevant ist, wenn die ausgegebenen Daten feste Formate haben, etwa JSON, PDF, Bilder, ...)
    c) mit trigger_error kann man bequem in die Logdatei schreiben, auch wenn die Ressource nicht "direkt" aufgerufen wurde (etwa mit AJAX, und eine Rückgabe gar nicht ausgewertet wird).

    Auf Windows nutze ich cygwin und das normale Unix-tail, aber ich habe auch schon Windows-native tail-Programme gesehen.

    Bis die Tage,
    Matti

    1. Ich würde dir empfehlen, auf die Anzeige von Fehlern im Browser komplett zu verzichten und stattdessen einfach mit "tail" oder einem ähnlichen Programm (am Besten mit "follow"-Funktion wie "tail -f" der Logdatei zu lauschen.

      Danke für die Idee, aber das muss doch auch so gehen?!?

      UPs. Vielleicht kommen wir jetzt weiter: die option log_errors ist auch gesetzt (laut WAMP-Konfiguration). Allerdings bleibt php_error.log total leer. Auch bei fehlendem ; am Zeilenende. Da stimmt doch irgendwas nicht!

      Hilfe, bitte.... Was kann ich noch probieren.?

      1. Hi!

        UPs. Vielleicht kommen wir jetzt weiter: die option log_errors ist auch gesetzt (laut WAMP-Konfiguration). Allerdings bleibt php_error.log total leer. Auch bei fehlendem ; am Zeilenende. Da stimmt doch irgendwas nicht!

        Neben dem on/off von log_errors ist auch noch der Wert von error_log wichtig.

        Lo!