Fehlermeldung sagt mir nichts

[Joseph]

Hallo,

eine JS-Funktion in meinem Script hat keine Funktion mehr.

Der Inspector von chrome meldet in der Konsole:

VM258:1 Uncaught SyntaxError: Unexpected token < in JSON at position 0
    at JSON.parse (<anonymous>)
    at Object.success (myJS.js?v=1553033493:484)
    at fire (jquery.js:3232)
    at Object.fireWith [as resolveWith] (jquery.js:3362)
    at done (jquery.js:9840)
    at XMLHttpRequest.callback (jquery.js:10311)
success	@	myJS.js?v=1553033493:484
fire	@	jquery.js:3232
fireWith	@	jquery.js:3362
done	@	jquery.js:9840
callback	@	jquery.js:10311
XMLHttpRequest.send (async)		
send	@	jquery.js:10254
ajax	@	jquery.js:9738
(anonymous)	@	myJS.js?v=1553033493:464
dispatch	@	jquery.js:5226
elemData.handle	@	jquery.js:4878

Was bedeutet das? Wo soll ich nach dem Fehler suchen?

Sepp

[dedlfix]

Tach!

VM258:1 Uncaught SyntaxError: Unexpected token < in JSON at position 0

Was bedeutet das?

Die Meldung beschwert sich über einen Syntaxfehler in JSON-Daten.

Wo soll ich nach dem Fehler suchen?

Zunächst in den Daten, die da über den XMLHttpRequest angefragt werden, damit du sehen kannst, was da defekt ist. Dann da, wo die Daten bereitgestellt werden, um das Problem zu beheben.

dedlfix.

[Raketenwissenschaftler]

Unexpected token < in JSON at position 0

Aufgrund des Umstandes, dass in dem erwartetem JSON an der ersten Stelle („at position 0“) ein sehr html-typisches „<“ detektiert wurde, würde ich zu der Behauptung neigen, dass statt des JSON eine Fehlermeldung vom Server kam.

ToDo:

• Man sollte sich also das "JSON" und dazu den HTTP-Status von dessen Aussendung mal in den Entwicklertools ansehen.
• Und danach die Programme(sic: beide!). Denn entweder sendet der Server den falschen Statuscode und/oder das empfangende Skript reagiert nicht angemessen darauf, dass ein anderer als der Statuscode 200 gesendet wurde.

[Joseph]

Unexpected token < in JSON at position 0

Aufgrund des Umstandes, dass in dem erwartetem JSON an der ersten Stelle („at position 0“) ein sehr html-typisches „<“ detektiert wurde, würde ich zu der Behauptung neigen, dass statt des JSON eine Fehlermeldung vom Server kam.

Viele Dank an Euch Beide.

Für Deinen Verdacht spricht auch, dass dasselbe script auf 2 anderen Server problemlos läuft (gerade erst gemerkt). Auf meinem Xammp aber nicht.

Sepp

[pl]

Unexpected token < in JSON at position 0

Aufgrund des Umstandes, dass in dem erwartetem JSON an der ersten Stelle („at position 0“) ein sehr html-typisches „<“ detektiert wurde, würde ich zu der Behauptung neigen, dass statt des JSON eine Fehlermeldung vom Server kam.

Es kann aber auch PHP sein was der Server schickt. Das beginnt auch mit < und dem seine Feststellung daß der Fehler nur auf einem Server (namens XAMPP) auftritt, deutet auch darauf hin (PHP wird nicht ausgeführt).

MFG

[Joseph]

Es kann aber auch PHP sein was der Server schickt. Das beginnt auch mit < und dem seine Feststellung daß der Fehler nur auf einem Server (namens XAMPP) auftritt, deutet auch darauf hin.

Danke, sehr guter Hinweis! Denn ich habe nach dem Umstieg auf ein neues Xammp immer wieder Proleme mit Notice und Warnings gehabt. Anscheinend war mein altes Xammp per php.ini darauf getrimmt, diese nicht zu zeigen. Nun habe ich im neuen Xammp mal testhalber die Notice und Warnings in der php.ini geaktiviert und schon läuft das Script.

Damit weiß ich ab hier wieder selber weiter, wie ich den fehler suchen und abstellen kann.

Dank an Eure Hilfe hier,

Sepp

[Auge]

Hallo

Es kann aber auch PHP sein was der Server schickt. Das beginnt auch mit < und dem seine Feststellung daß der Fehler nur auf einem Server (namens XAMPP) auftritt, deutet auch darauf hin.

Denn ich habe nach dem Umstieg auf ein neues Xammp immer wieder Proleme mit Notice und Warnings gehabt. Anscheinend war mein altes Xammp per php.ini darauf getrimmt, diese nicht zu zeigen. Nun habe ich im neuen Xammp mal testhalber die Notice und Warnings in der php.ini geaktiviert und schon läuft das Script.

Augen zu und durch! Wäre es nicht besser, die Meldungen auszuwerten und die Mängel zu beheben statt sie unter den Teppich zu kehren?

Damit weiß ich ab hier wieder selber weiter, wie ich den fehler suchen und abstellen kann.

Offensichtlich willst du genau das nicht tun.

Tschö, Auge

[Joseph]

Hi Auge,

Augen zu und durch! Wäre es nicht besser, die Meldungen auszuwerten und die Mängel zu beheben statt sie unter den Teppich zu kehren?

Damit weiß ich ab hier wieder selber weiter, wie ich den fehler suchen und abstellen kann.

Offensichtlich willst du genau das nicht tun.

Tschö, Auge

Dieses Forum könnte so nett sein, wenn nicht immer irgendwelche unwahren Unterstellungen in manche Beiträge einfließen würden.

Sepp

[Auge]

Hallo

Augen zu und durch! Wäre es nicht besser, die Meldungen auszuwerten und die Mängel zu beheben statt sie unter den Teppich zu kehren?

Damit weiß ich ab hier wieder selber weiter, wie ich den fehler suchen und abstellen kann.

Offensichtlich willst du genau das nicht tun.

Dieses Forum könnte so nett sein, wenn nicht immer irgendwelche unwahren Unterstellungen in manche Beiträge einfließen würden.

Das Posting, das du verlinkst und in dem du das Ergebnis deiner Fehlersuche präsentiertest, hatte ich, als ich meines schrieb, noch nicht gelesen.

Für mich klingt „Nun habe ich im neuen Xammp mal testhalber die Notice und Warnings in der php.ini geaktiviert und schon läuft das Script.“ (aus dem Posting, auf das ich antwortete) aber sehr nach „Aus den Augen, aus dem Sinn“, weshalb ich so deutlich insistierte. Zu wissen, wie man den Fehler behebt, kann ja grundsätzlich alles Mögliche bedeuten.

Nun, ich habe mich ganz offensichtlich geirrt. Tut mir leid, dich wegen meiner Fehlinterpretation so angegangen zu haben. Es ist halt leider allzuoft so, dass dieser Hinweis so deutlich formuliert werden muss, weil das unter den Teppich kehren für viele die einfache (aber oft nur vorläufige) Lösung ist.

Tschö, Auge

[Joseph]

Hi Auge,

Für mich klingt „Nun habe ich im neuen Xammp mal testhalber die Notice und Warnings in der php.ini geaktiviert und schon läuft das Script.“ (aus dem Posting, auf das ich antwortete) aber sehr nach „Aus den Augen, aus dem Sinn“, weshalb ich so deutlich insistierte. Zu wissen, wie man den Fehler behebt, kann ja grundsätzlich alles Mögliche bedeuten.

Nun, ich habe mich ganz offensichtlich geirrt. Tut mir leid, dich wegen meiner Fehlinterpretation so angegangen zu haben. Es ist halt leider allzuoft so, dass dieser Hinweis so deutlich formuliert werden muss, weil das unter den Teppich kehren für viele die einfache (aber oft nur vorläufige) Lösung ist.

Alles wieder gut. :-) Ich weiß, was Du meinst. Ich dachte, dass mein "testhalber" und mein "weiß, wie ich den Fehler behebe" ausdrückt, dass ich der Ursache auf den Grund gehe. Nach dem Umzug auf meinen neuen Xampp kämpfe ich ich unzähligen Scripten gerade mit den vielen Notice und Warnings. Daher fühlte ich mich mit dem Wissen, dass dieser kleine Error-Report-Teufel wieder zugeschlagen hatte, auf sicherem Terrain. Das ungefähr wollte ich in meinem beitrag ausdrücken. Ich weiß, dass es Entwickler gibt, die das Problem über dauerhaftes Deaktivieren dieser Reportmeldungen oder über error_reporting(0); "lösen".

Sepp

[Rolf B]

Hallo Joseph,

geaktiviert

du meinst deaktiviert? Denn aktiv waren sie ja...

Aber so unrecht hat Auge nicht. Denn so langsam macht mir dieser Thread irre. Ich schreibe mehrfach: Guck in den Netzwerktrace im Browser. Guck Dir an, was der Server liefert. Aber offenbar hast Du das nicht getan. Statt dessen fragst Du mehrfach nach, spekulierst herum, konfigurierst probehalber die php.ini um, und rufst den JSON-Request manuell im Browser auf, um überrascht die Warning zu entdecken.

Ich frage mich - nicht nur bei Dir: Sind die Entwicklerwerkzeuge im Browser irgendwie unanständiger Schweinkram? Ist es eine Schande, F12 zu drücken und 3x mit der Maus zu klicken, um sich den Response-Body direkt anzuschauen? Real Programmers Don't Use Traces, They Divine The Bug?

Rolf

[Joseph]

Aber so unrecht hat Auge nicht. Denn so langsam macht mir dieser Thread irre. Ich schreibe mehrfach: Guck in den Netzwerktrace im Browser. Guck Dir an, was der Server liefert. Aber offenbar hast Du das nicht getan.

Doch schon, aber dort nichts gefunden, was ich dem Prpblem hätte zuordnen können. Jetzt, da Du den Fehler kennst: Was hätte denn dort stehen müssen und wo genau?

Sepp

[Rolf B]

Hallo Joseph,

ich hatte es für die Antwort an Jörg und PL mal nachgebaut, mit einem Statischen Textfile statt einem PHP Request. Das benutze ich jetzt. Im Textfile steht

<b>Warning:</b> this is not the json you're looking for
[ 1,2,3,4 ]

In Chrome sieht das Netzwerk-Tab so aus:

Da steht jetzt fetch weil meine Testseite schon auf den fetch-Test umgestellt war. Bei jQuery würde da xhr stehen.

Klickt man dann auf die Zeile mit testdata.json, bekommt man

Das ist das Preview-Tab, in den anderen Tabs stehen weitere Informationen zum Request. Geschlossen wird der Details-View durch Klick auf das X neben Headers.

Beim Firefox wird es ähnlich aussehen.

Rolf

[Joseph]

Danke für die Arbeit, Rolf.

Ich wußte nicht, dass man das so macht, daher meine Ausweichlösung.

Sepp

[TS]

Hello,

Unexpected token < in JSON at position 0

Aufgrund des Umstandes, dass in dem erwartetem JSON an der ersten Stelle („at position 0“) ein sehr html-typisches „<“ detektiert wurde, würde ich zu der Behauptung neigen, dass statt des JSON eine Fehlermeldung vom Server kam.

ToDo:

• Man sollte sich also das "JSON" und dazu den HTTP-Status von dessen Aussendung mal in den Entwicklertools ansehen.
• Und danach die Programme(sic: beide!). Denn entweder sendet der Server den falschen Statuscode und/oder das empfangende Skript reagiert nicht angemessen darauf, dass ein anderer als der Statuscode 200 gesendet wurde.

Also als erstes Netzwerkkonsole im Browser öffnen und Statuscode angucken und dann ggf. die Payload?

Glück Auf
Tom vom Berg

[pl]

moin

Also als erstes Netzwerkkonsole im Browser öffnen

Nein. Das Erste ist die Fehlerbehandlung im Programm selbst.

MFG

[Der Martin]

Hallo,

Also als erstes Netzwerkkonsole im Browser öffnen

Nein. Das Erste ist die Fehlerbehandlung im Programm selbst.

ich hätte nicht gedacht, dass wir mal so einer Meinung sein könnten.
Aber ja: Erst mal die offensichtlichen Symptome betrachten. Und dann davon die Auswahl der Werkzeuge und Verfahren abhängig machen.

Merke: Man muss nicht gleich eine MRT machen, wenn der Patient deutlich sichtbar nur eine Schnittwunde hat.

So long,
 Martin

[pl]

Hallo,

Also als erstes Netzwerkkonsole im Browser öffnen

Nein. Das Erste ist die Fehlerbehandlung im Programm selbst.

ich hätte nicht gedacht, dass wir mal so einer Meinung sein könnten.

Das sind WIR ganz bestimmt nicht. MFG

[Tabellenkalk]

Hallo,

ich hätte nicht gedacht, dass wir mal so einer Meinung sein könnten.

Das sind WIR ganz bestimmt nicht. MFG

Weil du grundsätzlich immer anderer Meinung bist, oder warum?

Gruß
Kalk

[TS]

Hello,

Hallo,

Also als erstes Netzwerkkonsole im Browser öffnen

Nein. Das Erste ist die Fehlerbehandlung im Programm selbst.

ich hätte nicht gedacht, dass wir mal so einer Meinung sein könnten.
Aber ja: Erst mal die offensichtlichen Symptome betrachten. Und dann davon die Auswahl der Werkzeuge und Verfahren abhängig machen.

Merke: Man muss nicht gleich eine MRT machen, wenn der Patient deutlich sichtbar nur eine Schnittwunde hat.

Irgendwo muss die Fehlermeldung ja aufschlagen.

Bei einem ursprünglich laufenden Programmkonglomerat sollte der Userscreen die Fehlermeldung schließlich nicht anzeigen. Der sollte leer bleiben, oder bestenfalls einen Link mit "tut uns leid" zu einer übergeordneten Seite anzeigen.

Also nochmal von vorne:
Um herauszufinden, welche Ressource herumzickt, schaue ich zuerst in die (Netzwerk-)Konsole des Browsers, dann ins zugehörige Log, aus dem ich dann vielleicht die Fehlermeldung des OP herausfiltern konnte.

Erst dann kann ich im zugehörigen Programmmodul rund um die benannte Zeile schauen, ob ich mich z. B. vertippt habe oder ob ein logischer Fehler vorliegt, der dann zu unterschiedlichem Laufzeitverhalten ("Blinkerfehler") führt.

Der OP war der Ursache doch schon ziemlich nah gekommen, hat aber mMn keine sinnvolle Basisstrategie für die Anzeige/Behandlung/Unterdrückung/Logging [1] von Fehlern und für die Reihenfolge der Suchschritte, mit der man die Fehler dann finden kann.

Hier ist jetzt die Chance, über [1] zu diskutieren. Das läge mir am Herzen!
Und schließlich sollte auch ein Server nicht lügen, sondern einen passenden Statuscode senden.

Wie sollte man vorgehen?
Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Glück Auf
Tom vom Berg

[Der Martin]

Hallo,

Merke: Man muss nicht gleich eine MRT machen, wenn der Patient deutlich sichtbar nur eine Schnittwunde hat.

Irgendwo muss die Fehlermeldung ja aufschlagen.

ja, oder sie manifestiert sich indirekt in unpassenden Ergebnissen.

Bei einem ursprünglich laufenden Programmkonglomerat sollte der Userscreen die Fehlermeldung schließlich nicht anzeigen. Der sollte leer bleiben, oder bestenfalls einen Link mit "tut uns leid" zu einer übergeordneten Seite anzeigen.

Da bin ich dabei. Im Entwicklungsstadium darf das Programmkonglomerat, wie du es nennst, aber durchaus gesprächig sein. Nur muss der Entwickler die Informationen dann auch sehen und verstehen.

Um herauszufinden, welche Ressource herumzickt, schaue ich zuerst in die (Netzwerk-)Konsole des Browsers, dann ins zugehörige Log, aus dem ich dann vielleicht die Fehlermeldung des OP herausfiltern konnte.

Gut. Und ich schaue mir, bevor ich die Superwaffe "Developer Tools" zücke, erstmal aus Client-Sicht an: Was bekomme ich überhaupt? Oft erkenne ich daraus schon, was das Problem ist, und muss gar nicht erst den Phaser benutzen.

Erst dann kann ich im zugehörigen Programmmodul rund um die benannte Zeile schauen, ob ich mich z. B. vertippt habe oder ob ein logischer Fehler vorliegt, der dann zu unterschiedlichem Laufzeitverhalten ("Blinkerfehler") führt.

Wir haben also unterschiedliche Indikatoren, verfolgen aber im Prinzip die gleiche Strategie. Ich versuche es mit den (aus meiner Sicht) einfachen Mitteln, du gehst gleich mit der MRT los, um den Vergleich nochmal aufzugreifen.

Der OP war der Ursache doch schon ziemlich nah gekommen, hat aber mMn keine sinnvolle Basisstrategie für die Anzeige/Behandlung/Unterdrückung/Logging [1] von Fehlern und für die Reihenfolge der Suchschritte, mit der man die Fehler dann finden kann.

Ja. Das ist vermutlich der geringen Erfahrung im Debugging geschuldet. Daraus würde ich aber nur demjenigen einen Vorwurf stricken, der das schon jahrelang oder sogar beruflich macht.

Hier ist jetzt die Chance, über [1] zu diskutieren. Das läge mir am Herzen!

Meinetwegen gern. Einen Ansatz habe ich schon von mir gegeben.

Und schließlich sollte auch ein Server nicht lügen, sondern einen passenden Statuscode senden.

Auch dazu habe ich mich in eben diesem Beitrag schon geäußert.

Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Im Gegenteil. Während der Entwicklung sollte man alle nur denkbaren Quellen für Hinweise und Meldungen belauschen.

Ciao,
 Martin

[TS]

Hello,

Da bin ich dabei. Im Entwicklungsstadium darf das Programmkonglomerat, wie du es nennst, aber durchaus gesprächig sein.

Um herauszufinden, welche Ressource herumzickt, schaue ich zuerst in die (Netzwerk-)Konsole des Browsers, dann ins zugehörige Log, aus dem ich dann vielleicht die Fehlermeldung des OP herausfiltern konnte.

Gut. Und ich schaue mir, bevor ich die Superwaffe "Developer Tools" zücke, erstmal aus Client-Sicht an: Was bekomme ich überhaupt? Oft erkenne ich daraus schon, was das Problem ist, und muss gar nicht erst den Phaser benutzen.

Da es diejenige Diagnosemöglickeit ist, die ich an einem DT-Platz direkt vor mir habe, sehe ich das keinesfalls als das "MRT" der Fehlersuche an. Das wäre mMn, WireShark anzuschmeißen, o. ä.

Erst dann kann ich im zugehörigen Programmmodul rund um die benannte Zeile schauen, ob ich mich z. B. vertippt habe oder ob ein logischer Fehler vorliegt, der dann zu unterschiedlichem Laufzeitverhalten ("Blinkerfehler") führt.

Wir haben also unterschiedliche Indikatoren, verfolgen aber im Prinzip die gleiche Strategie. Ich versuche es mit den (aus meiner Sicht) einfachen Mitteln, du gehst gleich mit der MRT los, um den Vergleich nochmal aufzugreifen.

Der OP war der Ursache doch schon ziemlich nah gekommen, hat aber mMn keine sinnvolle Basisstrategie für die Anzeige/Behandlung/Unterdrückung/Logging [1] von Fehlern und für die Reihenfolge der Suchschritte, mit der man die Fehler dann finden kann.

Ja. Das ist vermutlich der geringen Erfahrung im Debugging geschuldet. Daraus würde ich aber nur demjenigen einen Vorwurf stricken, der das schon jahrelang oder sogar beruflich macht.

Hier ist jetzt die Chance, über [1] zu diskutieren. Das läge mir am Herzen!

Meinetwegen gern. Einen Ansatz habe ich schon von mir gegeben.

Nur bist Du bisher nicht darauf eingegangen, dass man immer alle möglichen Fehlermeldungen nutzen sollte und wie man das dann zweckmäßigerweise organisiert. Wer sich darüber nicht vor der Programmcodierung bereits Gedanken macht, hat den schlimmsten Fehler schon eingebaut, bevor er überhaupt die erste Zeile Code geschrieben hat.

Und schließlich sollte auch ein Server nicht lügen, sondern einen passenden Statuscode senden.

Auch dazu habe ich mich in eben diesem Beitrag schon geäußert.

Gut :-)

Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Im Gegenteil. Während der Entwicklung sollte man alle nur denkbaren Quellen für Hinweise und Meldungen belauschen.

Man sollte immer alle möglichen Meldungen nutzen!
Die Frage ist nur, wo man sie auflaufen lässt.

Alle Programmierfehler (und damit auch die Notices) sollten zur Entwicklungszeit beseitigt werden. Behandelbare Laufzeitfehler sollten zur Laufzeit behandelt werden, ggf. mif Roundturn und Zwischenanweisungen an den User.

Nicht behandelbare Laufzeitfehler sollten logged werden und auch zeitnah angeschaut. Bei schweren Fehlern dann z.B. eMail an den Admin. Ggf. Zwangsstopp der Applikation einleiten (Generelle "zur Zeit außer Betrieb"-Meldung) für den Userscreen.

Zugriffsfehler (Auth) sollten in einem separaten Log auflaufen, dessen Format von fail2ban auswertbar ist.

Wer es sich angewöhnt, schon zur Entwicklungszeit Fehlermeldungen auf dem Userscreen zu vermeiden und dort konsequent nur Anweisungen an den User und was er eben sonst so sehen soll/will, unterzubringen, der hat später zur Laufzeit keinen Ärger mehr damit.

Glück Auf
Tom vom Berg

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

Um herauszufinden, welche Ressource herumzickt, schaue ich zuerst in die (Netzwerk-)Konsole des Browsers, dann ins zugehörige Log, aus dem ich dann vielleicht die Fehlermeldung des OP herausfiltern konnte.

Wenn es nicht offensichtlich ist, wo der Fehler stecken muss, würde ich auch zuerst die Konsole des Browsers öffnen. Das geht am schnellsten. Man hat sie schließlich direkt vor der Nase.

Ich gehe dabei davon aus, dass im Frontend keine Fehlermeldungen angezeigt werden.

Spirituelle Grüße
Euer Robert

[pl]

moin

Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Natürlich nicht, das Gegenteil musst Du tun, nämlich dafür sorgen, daß alle Fehlermeldung sofort sichtbar werden und auch die Warnungen. Nur so kannst Du sicherstellen daß eine Anwendung fehlerfrei rausgeht.

Denn wenn sie einmal draußen ist, bist Du im Fehlerfall auf das angewiesen was der User Dir erzählt, sollte da dennoch ein Fehler drinstecken.

MFG

[TS]

Hello,

Das totale Abschalten und Ignorieren von Fehlermeldungen kann es doch nicht sein!?

Natürlich nicht, das Gegenteil musst Du tun, nämlich dafür sorgen, daß alle Fehlermeldung sofort sichtbar werden und auch die Warnungen. Nur so kannst Du sicherstellen daß eine Anwendung fehlerfrei rausgeht.

Denn wenn sie einmal draußen ist, bist Du im Fehlerfall auf das angewiesen was der User Dir erzählt, sollte da dennoch ein Fehler drinstecken.

Hier geht es um Dialogprogramme (Client-Server im Web). Die gehen nicht "raus", werden aber irgendwann freigegeben zur Benutzung. Zu diesem Zeitpunkt sollte es keine Notices oder sonstige Fehlermeldungen wegen Programmierfehlern mehr geben.

Zudem sind Webapplikationen i. d. R. Multiuserprogramme. Sie bleiben daher auch leicht für den Ersteller im Visier.

Trotzdem gehören Fehlermeldungen nicht auf den Userscreen. Dorthin gehören nur Anweisungen und Meldungen, die auch für die Enduser bestimmt sind. Und das sollte man mMn von Anfang an so berücksichtigen. Die Zeiten von Einschirm (17") Entwicklerplätzen sind mit hoher Wahrscheinlichkeit vorbei.

BTW:
Wie kann man unter Windows soetwas wie tail -f einrichten, um die Fehlermeldungen in Echtzeit in einem eigenen Fenster (auf einem separaten Screen) anzeigen zu lassen?

Glück Auf
Tom vom Berg

[Mitleser]

Wie kann man unter Windows soetwas wie tail -f einrichten, um die Fehlermeldungen in Echtzeit in einem eigenen Fenster (auf einem separaten Screen) anzeigen zu lassen?

https://de.wikipedia.org/wiki/Windows_Subsystem_for_Linux

[TS]

Hello,

Wie kann man unter Windows soetwas wie tail -f einrichten, um die Fehlermeldungen in Echtzeit in einem eigenen Fenster (auf einem separaten Screen) anzeigen zu lassen?

https://de.wikipedia.org/wiki/Windows_Subsystem_for_Linux

Danke für den Tipp. Wusste ich auch noch nicht.
Ich habe hauptsächlich nur noch Linux und Android laufen.

Glück Auf
Tom vom Berg

[pl]

Wie kann man unter Windows soetwas wie tail -f einrichten, um die Fehlermeldungen in Echtzeit in einem eigenen Fenster (auf einem separaten Screen) anzeigen zu lassen?

mTail.exe (auch bei heisedownloads)

Ein separater Screen ist da jedoch nicht enthalten. MFG

[Rolf B]

Hallo Sepp,

(Edit: Verdammt, meine eigene Rakete war zu langsam)

die Meldung klingt nach einem Folgefehler. HTML beginnt mit <, JSON nicht. Der Server hat vermutlich eine Fehlermeldung zurückgegeben und die JSON Meldung ist ein Folgefehler.

Verwende den Netzwerktrace deines Browsers, um Dir den HTTP Status und den Inhalt der Antwort auf den AJAX Requests anzuschauen

Die weiteren Aktivitäten hängen davon ab, was Du dabei herausfindest.

Wenn Du weitere Rückfragen hast, zeige uns bitte, wie Du mit jquery den Ajax-Request absetzt.

Rolf

[Joseph]

Wenn Du weitere Rückfragen hast, zeige uns bitte, wie Du mit jquery den Ajax-Request absetzt.

Hallo Rolf,

ja, weitere Probleme.

Netzwerktool sagt, dass das script den code200 zurückgibt, das würde ja passen.

$('#save').on('click', function(){
$.ajax ({
                type: 'POST',
                url: './testscript.php',
                data: { 
                ...
                },
                success : function(data) {
                var einzeldata = JSON.parse( data );
                // Verarbeitung der Daten
                },
                error:function(e){
                alert("Ajax Error");}
            });
    });

Sepp

[Rolf B]

Hallo Joseph,

very well. Du machst die JSON-Behandlung also manuell. Das erlaubt ggf. eine Sonderbehandlung von HTTP Antworten - falls das denn nötig werden sollte. Aber wahrscheinlich wird es das nicht.

Und jetzt bin ich gespannt, was Du aus dem Netzwerktrace erfährst.

Rolf

[pl]

Du machst die JSON-Behandlung also manuell

Er benutzt jQuery. Aber interessant, daß jQuery die Exception gar nicht fängt die da auftritt. Von einem Framework wie jQuery könnte man sowas schon erwarten.

MFG

[Rolf B]

Hallo pl,

das kann man überlegen, aber ich bin nicht so sicher, ob das eine sinnvolle Reaktion von jQuery wäre. Was soll es mit der Exception machen? Einfach verschlucken ist nicht korrekt, und der error Callback hat eine andere Aufgabe: "A function to be called if the request fails." sagt die Doku, und der Request war ja erfolgreich (Status 200 sagt Sepp).

Es mag etwas anderes sein, wenn man datatype: "JSON" hinzufügt, dann erledigt jQuery die Konvertierung und der Fehler tritt unter der Hoheit der Lib auf.

Es mag auch etwas anderes sein, wenn man das Deferred (aka Promise) Interface der Ajax-Funktionen verwendet.

Rolf

[Joseph]

ist ein Warning des aufgerufenen Php-Scriptes.

Hi Martin,

hast du die erzeugte JSON-Ressource mal direkt im Browser aufgerufen? Das würde ich als nächstes tun. Dann siehst du in der Quellcodeansicht, was wirklich gesendet wird (z.B. eine Server-Fehlermeldung oder nicht ausgeführtes PHP).

Genau mein Gedanke, nachdem ich wußte, dass ein Notice oder Warning dahinter stecken muß:

Warning: Invalid argument supplied for foreach() in H:\xampp\htdocs\project221\testscript.php on line 187
[{"id":"2","wert":"Fehler: Eingabe fehlt!","typ":"Error","ggs":0}] 

Damit ist klar, ich habe vergessen, dass ich das Array in Zeile 187 auf empty() prüfen sollte.

Sepp

https://forum.selfhtml.org/self/2020/feb/13/fehlermeldung-sagt-mir-nichts/1765087#m1765087

Dank nochmal ans Forum,

Sepp

[Raketeninspektor]

Ich nehm ja lieber das Vanilla-NoFramework, aber zur Ehrenrettung von jquery:

• jquery bietet mannigfaltig Möglichkeiten, die Exception fest zu stellen und zu reagieren.
• Nur wird das - offenbar bewusst - dem Verwender überlassen.

[pl]

Ich nehm ja lieber das Vanilla-NoFramework, aber zur Ehrenrettung von jquery:

• jquery bietet mannigfaltig Möglichkeiten, die Exception fest zu stellen und zu reagieren.
• Nur wird das - offenbar bewusst - dem Verwender überlassen.

OK 😉

Aber für Ajaxkram braucht man jQuery ja nun wirklich nicht. Und gerade hier zeigt es sich, daß es auch darauf ankommt, den serverseitigen Status mit einzubeziehen in die Fehlerbehandlung. D.h., daß man bei einem xhr.status != 200 keinen JSON in der Response zu erwarten und zu parsen hat.

MFG

[Rolf B]

Ihr könnt reden...

Aber ihr habt schon wahrgenommen, dass der HTTP Status bei Sepp 200 war? Das war also kein Grund für jQuery, in den error-Handler zu springen.

Er hat aber auch keine Angabe für dataType gemacht. Mit dataType: "json" in den Optionen funktioniert es nämlich, dann springt jQuery in den Error-Handler statt in den Success-Handler (soeben validiert). Und wenn der Error-Handler dann auch noch seinen 3. Parameter protokollieren würde, statt nur "Aua" zu schreien, dann hätte da auch gleich die Fehlermeldung des JSON-Parsers gestanden.

  $.ajax ({ type: 'GET', 
            url: './testdata.json',
            dataType: "json", 
            success: ProcessData,
            error: HandleError });

  function ProcessData(data) {
     // JSON.parse hier nicht mehr nötig
  }

  function HandleError(xhr, textStatus, errorThrown) {
    console.log(`Ajax Error, Status ${xhr.status} (${textStatus}, ${errorThrown})`);
  }

In der Konsole wird ausgegeben:

Ajax Error, Status 200 (parsererror, SyntaxError: Unexpected token < in JSON at position 0)

Mit dem plain vanilla fetch API muss man HTTP Fehler übrigens selbst erkennen (bei jQuery erledigt das die Lib), aber der .json() Konverter rejected immerhin sein Promise. Also, so GANZ bequem ist das auch nicht, und ein nackiger XMLHttpRequest ist noch mehr Mühe (sofern man ihn nicht in seinem Framework kapselt).

fetch("./testdata.json")
    .then(function(response) { 
       if (response.ok)
          return response.json();
       else
          throw `Ajax Error, Status ${response.status} ${response.statusText}`;
    })
    .then(ProcessData)
    .catch(HandleError);

Rolf

[pl]

Ihr könnt reden...

Ok, reden wir.

Aber ihr habt schon wahrgenommen, dass der HTTP Status bei Sepp 200 war?

Genau das ist das Problem einer mangelhaften Fehlerbehandlung. Status 200 ist schon falsch.

Er hat aber auch keine Angabe für dataType gemacht. Mit dataType: "json" in den Optionen funktioniert es nämlich, dann springt jQuery in den Error-Handler

Wenn der Fehler, so wie hier serverseitig auftritt, kann man keinen JSON erwarten.

That's the Crux.

[Rolf B]

Hallo pl,

That's the Crux.

Ich bin einverstanden, dass ein sauber programmierter und getesteter Server keinen HTTP 200 Status bringen sollte, wenn er kein JSON auf einen JSON-Request liefert. Aber die Welt ist nun mal böse und gemein, darum:

Ich bin nicht einverstanden, dass sich ein Client darauf verlassen darf, dass der Server sauber programmiert und getestet ist. Er muss dann sinnvolle Meldungen ausgeben und nicht blindlings vor die nächste Wand rennen.

Ich gebe zu, dass das zu lästigeren Arbeiten des Programmierhandwerks gehört und von vielen vernachlässigt wird. Aber genau deswegen hat Sepp seinen Serverfehler nicht sofort erkannt.

Rolf

[pl]

That's the Crux.

Ich bin einverstanden, dass ein sauber programmierter und getesteter Server keinen HTTP 200 Status bringen sollte, wenn er kein JSON auf einen JSON-Request liefert.

Es geht doch gar nicht um den JSON. Sondern darum daß es sich auch im Status ausdrücken sollte wenn es serverseitig knallt.

Ich bin nicht einverstanden, dass sich ein Client darauf verlassen darf, dass der Server sauber programmiert und getestet ist.

Ein Client muss erkennen können ob der Server ein Problem hat. Und dafür fragt ein Client gewöhnlich den Status ab. Und zwar als Erstes und bevor eine Response verarbeitet wird. Dafür gibt es den Status auch in der 1. Zeile einer jeden HTTP Response.

Ergo muss sich ein Client darauf verlassen können daß der Status zur Response passt. Was hier nicht der Fall ist.

MFG

[Der Martin]

n'Abend,

Es geht doch gar nicht um den JSON. Sondern darum daß es sich auch im Status ausdrücken sollte wenn es serverseitig knallt.

ja, wir kommen hier aber zu einem konzeptionellen Problem von PHP: Da gibt es nicht nur Ja und Nein, sondern eben auch oft ein "Jein". PHP meldet mit einer Notice oder Warning, dass irgendwas nicht stimmt, versucht aber, das Beste daraus zu machen und liefert das Ergebnis dann trotzdem mit dem "Gut"-Stempel. Eine so weitreichende Fehlertoleranz ist kontraproduktiv, finde ich.

Also der Angestellte (PHP) weiß, dass es ein Problem gibt und vermerkt das auch in den Papieren, meldet aber dem Chef (Apache), es sei alles in Ordnung. Der Chef gibt diese Info an den Kunden weiter, der Kunde glaubt das zunächst, ist dann aber verunsichert, weil in den Frachtpapieren seltsame Einschränkungen stehen.

Ich bin nicht einverstanden, dass sich ein Client darauf verlassen darf, dass der Server sauber programmiert und getestet ist.

Ich auch nicht, aber ich bin ebensowenig einverstanden, dass die Hilfsarbeiter einfach behaupten, es sei alles okay, obwohl das offensichtlich nicht so ist.

Ergo muss sich ein Client darauf verlassen können daß der Status zur Response passt. Was hier nicht der Fall ist.

Genau. Das klappt nämlich nur dann, wenn sich der Server auch auf seine Hilfsarbeiter verlassen kann.

Ciao,
 Martin

[TS]

Hello,

daraus könntest Du prima einen Comic machen ;-)

Glück Auf
Tom vom Berg

[Matthias Apsel]

Hallo Der Martin,

Also der Angestellte (PHP) weiß, dass es ein Problem gibt und vermerkt das auch in den Papieren, meldet aber dem Chef (Apache), es sei alles in Ordnung. Der Chef gibt diese Info an den Kunden weiter, der Kunde glaubt das zunächst, ist dann aber verunsichert, weil in den Frachtpapieren seltsame Einschränkungen stehen.

Jetzt weiß ich wieder, was ich zwei Jahre vermisst habe.

Bis demnächst
Matthias

[Der Martin]

Guten Abend Matthias,

Jetzt weiß ich wieder, was ich zwei Jahre vermisst habe.

herzlichen Dank für die Blumen. :-)

Ciao,
 Martin

[Rolf B]

Hallo Martin,

Eine so weitreichende Fehlertoleranz ist kontraproduktiv, finde ich.

Ja, das finde ich auch. Ein leeres Array bringt die Warnung nicht, es muss schon nicht-iterierbar sein (0, "", NULL). Aber da darf man gerne auch mal FATAL werden und die 2xx-er Komfortzone verlassen.

Es kann auch andere Gründe geben, gerade in der Entwicklung, weshalb ein PHP Programm seine Ausgabe mal mit unerwünschten Zusätzen garniert. Sie SOLLTEN nicht vorkommen, das ist richtig.

Ein Client, in der Rolle des Postboten, darf sich darüber aber trotzdem nicht wortlos erbrechen, sondern muss höflich aber bestimmt sagen können: Lieber Kunde, der Absender Winnetou hat mir leider ein Paket geliefert, das spitze Kanten hat und wo der Zettel Warnung: bla bla blub draufklebt. Das stelle ich Ihnen nicht zu. Bitte lassen sie sich etwas sinnvolleres schicken. Auf mehr wollte ich ja gar nicht hinaus.

Rolf

[Raketenfehlerfinder]

ja, wir kommen hier aber zu einem konzeptionellen Problem von PHP: Da gibt es nicht nur Ja und Nein, sondern eben auch oft ein "Jein". PHP meldet mit einer Notice oder Warning, dass irgendwas nicht stimmt, versucht aber, das Beste daraus zu machen und liefert das Ergebnis dann trotzdem mit dem "Gut"-Stempel. Eine so weitreichende Fehlertoleranz ist kontraproduktiv, finde ich.

Aber halt, Leute!

Es gab doch hier inzwischen schon mal zwei Übereinkünfte:

1. Ein Programm ist fertig, wenn es keine Notizen mehr wirft.
2. Auf produktiven(sic!) Servern hat die PHP-Einstellung für display_errors auf off zu stehen um Angreifern keine Hinweise zu liefern.

• Gegen beides wurde hier verstoßen.

Dazu käme hier ein weiterer Punkt:

• Fällt ein „Fehler“ vom Typ „Notiz“ an ist dieser abzufangen und möglicherweise als fatal zu behandeln.

[Der Martin]

Moin,

1. Ein Programm ist fertig, wenn es keine Notizen mehr wirft.

oh nein, keineswegs. Ein Programm ist nie wirklich fertig. Es gibt immer etwas zu pflegen, nachzubessern, zu ergänzen ... Das ist ein bisschen wie bei einer Modellbahnanlage: Die ist auch nie fertig.

2. Auf produktiven(sic!) Servern hat die PHP-Einstellung für display_errors auf off zu stehen um Angreifern keine Hinweise zu liefern.

Wir wissen aber nicht, ob es hier um ein Produktivsystem geht. Der Hinweis, dass dasselbe Script auf zwei anderen Maschinen (anscheinend) fehlerfrei laufe, sagt darüber nichts aus (es könnten auch alternative Testumgebungen sein).

• Fällt ein „Fehler“ vom Typ „Notiz“ an ist dieser abzufangen und möglicherweise als fatal zu behandeln.

Sag ich doch. Deswegen meine Kritik an PHP, dass ein Script in diesem Fall trotzdem mit dem Resultat OK durchläuft.

Ciao,
 Martin

[MudGuard]

Hi,

1. Ein Programm ist fertig, wenn es keine Notizen mehr wirft.

Sollte es nicht zusätzlich auch noch die ihm zugedachte Arbeit erledigen?

Ansonsten passiert sowas:

Schreiben Sie ein PHP-Programm, daß den nächsten Börsencrash vorhersagt!

Ok, mach ich:

<?php

Wirft keine Fehler oder Notices ⇒ Programm ist fertig.

cu,
Andreas a/k/a MudGuard

[TS]

Hello,

Es gab doch hier inzwischen schon mal zwei Übereinkünfte:

1. Ein Programm ist fertig, wenn es keine Notizen mehr wirft.

Ich formuliere das mal so, wie Du es vermutlich gemeint hast:

Eine Webapplikation kann veröffentlicht werden, wenn sie ihre Aufgaben erfüllt und keine Notices und/oder Fehlermeldungen mehr wirft wegen Programmierfehlern.

Mal sehen, welches Haar in der Formulierung die Bewusstverkehrtversteher nun noch finden ;-P

Glück Auf
Tom vom Berg

[Der Martin]

Hallo,

$('#save').on('click', function(){
$.ajax ({
                type: 'POST',
                url: './testscript.php',
                data: { 
                ...
                },
                success : function(data) {
                var einzeldata = JSON.parse( data );
                // Verarbeitung der Daten
                },
                error:function(e){
                alert("Ajax Error");}
            });
    });

hast du die erzeugte JSON-Ressource mal direkt im Browser aufgerufen? Das würde ich als nächstes tun. Dann siehst du in der Quellcodeansicht, was wirklich gesendet wird (z.B. eine Server-Fehlermeldung oder nicht ausgeführtes PHP).

Ciao,
 Martin

[Joseph]

Hi Martin,

hast du die erzeugte JSON-Ressource mal direkt im Browser aufgerufen? Das würde ich als nächstes tun. Dann siehst du in der Quellcodeansicht, was wirklich gesendet wird (z.B. eine Server-Fehlermeldung oder nicht ausgeführtes PHP).

Genau mein Gedanke, nachdem ich wußte, dass ein Notice oder Warning dahinter stecken muß:

Warning: Invalid argument supplied for foreach() in H:\xampp\htdocs\project221\testscript.php on line 187
[{"id":"2","wert":"Fehler: Eingabe fehlt!","typ":"Error","ggs":0}] 

Damit ist klar, ich habe vergessen, dass ich das Array in Zeile 187 auf empty() prüfen sollte.

Sepp