Fehlerbehandlung ajax//fetch

[pl]

Guten Morgen,

wie macht Ihr das eigentlich? Also wenn der Request am Server einen Fehler oder eine Exception wirft?

Bitte mal um Inspirations. MfG

[Matthias Apsel]

Hallo pl,

wie macht Ihr das eigentlich?

Uns fehlt wichtiges Grundwissen.

Bis demnächst
Matthias

[pl]

Hallo pl,

wie macht Ihr das eigentlich?

Uns fehlt wichtiges Grundwissen.

Gerade deswegen frage ich ja!

[Tabellenkalk]

Hallo,

Gerade deswegen frage ich ja!

Mit anderen Worten: die Antworten die hier kommen, wirst du nicht gelten lassen, sondern deine bisherige Lösung als die einzig Richtige präsentieren?!

Gruß
Kalk

[pl]

Hallo,

Gerade deswegen frage ich ja!

Mit anderen Worten: die Antworten die hier kommen, wirst du nicht gelten lassen, sondern deine bisherige Lösung als die einzig Richtige präsentieren?!

Ne ich frage weil ich was wissen will. Aber diejenigen die hier Beiträge bewerten sollten sich mal fragen warum sie das tun und ob ihr Wissen dazu hinreichend ist.

MfG

[JürgenB]

Hallo Rolf,

wie macht Ihr das eigentlich?

Uns fehlt wichtiges Grundwissen.

Gerade deswegen frage ich ja!

also prüfst du uns jetzt.

Gruß
Jürgen

[pl]

hi Jürgen

wie macht Ihr das eigentlich?

Uns fehlt wichtiges Grundwissen.

Gerade deswegen frage ich ja!

also prüfst du uns jetzt.

Nein. Ich bin nur auf der Suche nach neuen Ideen.

MfG

[pl]

Um den Komplex mal ein bischen einzugrenzen:

Ajax, xhr Objekt, xhr.responseType="arraybuffer"; Auf dem Server fällt eine Exception, was ist hier die BestPractice bez. Fehlerbehanlung?

MfG

[Robert B.]

Hallo pl,

Ajax, xhr Objekt, xhr.responseType="arraybuffer"; Auf dem Server fällt eine Exception, was ist hier die BestPractice bez. Fehlerbehanlung?

Response ist doch die Antwort vom Server. Meinst du das wirklich oder Request-Type?

Unabhängig davon wäre wohl ein entsprechender HTTP-Status-Code sinnvoll.

Viele Grüße
Robert

[pl]

hi

Ajax, xhr Objekt, xhr.responseType="arraybuffer"; Auf dem Server fällt eine Exception, was ist hier die BestPractice bez. Fehlerbehanlung?

Response ist doch die Antwort vom Server.

Genau.

Meinst du das wirklich oder Request-Type?

Na ich meine schon den responseType.

Unabhängig davon wäre wohl ein entsprechender HTTP-Status-Code sinnvoll.

Das ist schonmal eine gute Idee. Was machen wir mit der Fehlermeldung? Also auf welchem Wege kommt die zurück?

MfG

[dedlfix]

Tach!

Was machen wir mit der Fehlermeldung? Also auf welchem Wege kommt die zurück?

statustext oder response, such dir was aus. Wenn der Server nicht in der Lage war, die Antwortdaten in der gewünschten Form zusammenzustellen, dann muss man ja nicht zwangsläufig die Fehlermeldung in denselben Content-Type einpacken. Sende einen einfachen Text oder auch ein Objekt in Json-Format.

dedlfix.

[pl]

Tach!

Was machen wir mit der Fehlermeldung? Also auf welchem Wege kommt die zurück?

statustext oder response, such dir was aus. Wenn der Server nicht in der Lage war, die Antwortdaten in der gewünschten Form zusammenzustellen, dann muss man ja nicht zwangsläufig die Fehlermeldung in denselben Content-Type einpacken. Sende einen einfachen Text oder auch ein Objekt in Json-Format.

Bedenke, responseType ist ein ArrayBuffer. Du müsstest also serverseitig die Fehlermeldung entsprechend verpacken und clientseitig aus dem ArrayBuffer über ein StringView den String in ein JSON umwandeln um dann aus dem JSON die Fehlermeldung zu ziehen. Das erscheint mir ziemlich umständlich 😉

MfG

[Robert B.]

Hallo pl,

Bedenke, responseType ist ein ArrayBuffer.

bedenke, dass per Spezifikation responseType ein string ist.

Viele Grüße
Robert

[dedlfix]

Tach!

statustext oder response, such dir was aus. Wenn der Server nicht in der Lage war, die Antwortdaten in der gewünschten Form zusammenzustellen, dann muss man ja nicht zwangsläufig die Fehlermeldung in denselben Content-Type einpacken. Sende einen einfachen Text oder auch ein Objekt in Json-Format.

Bedenke, responseType ist ein ArrayBuffer.

Hmm, responseType muss man vor dem Request-Abschicken setzen und der lässt sich im Zustand DONE nicht mehr ändern. Dann bleibt dir nur der statusText.

Du müsstest also serverseitig die Fehlermeldung entsprechend verpacken und clientseitig aus dem ArrayBuffer über ein StringView den String in ein JSON umwandeln um dann aus dem JSON die Fehlermeldung zu ziehen. Das erscheint mir ziemlich umständlich 😉

Wenn du nicht ohne wirkliche Not mit Binärzeugs hantieren würdest, dann hättest du mit JSON die besseren Karten, was die Flexibilität des Inhalts anbelangt.

dedlfix.

[pl]

Tach!

statustext oder response, such dir was aus. Wenn der Server nicht in der Lage war, die Antwortdaten in der gewünschten Form zusammenzustellen, dann muss man ja nicht zwangsläufig die Fehlermeldung in denselben Content-Type einpacken. Sende einen einfachen Text oder auch ein Objekt in Json-Format.

Bedenke, responseType ist ein ArrayBuffer.

Hmm, responseType muss man vor dem Request-Abschicken setzen und der lässt sich im Zustand DONE nicht mehr ändern. Dann bleibt dir nur der statusText.

Es gibt mehrere Möglichkeiten. Aber den statusText würde ich da außen vorlassen und besser einen custom Header mit dem entsprechenden Fehlertext veranlassen.

Oder man nimmt den ArrayBuffer und zieht mit einem StringView die Fehlermeldung da raus.

Wenn du nicht ohne wirkliche Not mit Binärzeugs hantieren würdest, dann hättest du mit JSON die besseren Karten, was die Flexibilität des Inhalts anbelangt.

Das Problem mit xhr.responseType="json" ist, daß eben auch die Erstellung einer JSON Response auf dem Server schiefgehen kann, z.B. wenn ein SQL Statement fehlschlägt.

Dann müsste man für die Fehlermeldung dann auch einen extra JSON erzeugen.

Gibt es Artikel die sich näher mit diesem Thema befassen?

MfG

[dedlfix]

Tach!

Das Problem mit xhr.responseType="json" ist, daß eben auch die Erstellung einer JSON Response auf dem Server schiefgehen kann, z.B. wenn ein SQL Statement fehlschlägt.

Dann müsste man für die Fehlermeldung dann auch einen extra JSON erzeugen.

Beispielsweise das. Andererseits ist die generelle Erstellung der Antwort nicht davon abhängig, ob das SQL-Statement fehlschlägt oder nicht. Den Fehler kann man abfangen, bevor man die Antwort formuliert. Im Notfall hat das Framework noch einen generellen Abfangmechanismus, aber der sollte für die erwartbaren Fehler nicht eingreifen müssen. Das Fangen vor Ort wäre sinnvoller, weil man da spezifischer reagieren kann.

dedlfix.

[pl]

Tach!

Das Fangen vor Ort wäre sinnvoller, weil man da spezifischer reagieren kann.

Eben. Und i.d.R. sind die Texte von Exceptions eben nur Text und kein JSON. D.h., daß man diese Exceptions ohnehin auffangen muss wenn man mit dem Text noch einen JSON erstellen will.

MfG

[dedlfix]

Tach!

Hmm, responseType muss man vor dem Request-Abschicken setzen und der lässt sich im Zustand DONE nicht mehr ändern. Dann bleibt dir nur der statusText.

Man hat das Problem mit dem responseType gleich gar nicht mehr, wenn man statt XHR die Fetch API nimmt. Da kann man ohne weitere Festlegungen treffen zu müssen auf response.blob(), response.arrayBuffer() oder response.json() zugreifen, wie es beliebt. Was man davon nehmen muss, kann man ja anhand des Statuscodes entscheiden.

dedlfix.

[pl]

Tach!

Hmm, responseType muss man vor dem Request-Abschicken setzen und der lässt sich im Zustand DONE nicht mehr ändern. Dann bleibt dir nur der statusText.

Man hat das Problem mit dem responseType gleich gar nicht mehr, wenn man statt XHR die Fetch API nimmt. Da kann man ohne weitere Festlegungen treffen zu müssen auf response.blob(), response.arrayBuffer() oder response.json() zugreifen, wie es beliebt. Was man davon nehmen muss, kann man ja anhand des Statuscodes entscheiden.

Gute Idee, hast Du wohl von mir 😉

Ne, im Ernst, auf die Idee kann jeder kommen. Schließlich kochen wir alle nur mit Wasser 😉

MfG

[Rolf B]

gestrichen. das problem mit dem vorab-setzen des response-type hatte ich übersehen

[dedlfix]

Tach!

Es ist jetzt nur am Zuhörer, den Unterschied zwischen Trompetenspiel und Husten zu erkennen und dementsprechend die Darbietung zu genießen oder die Nase zu rümpfen.

Das Problem an der Stelle ist nur - und das hab ich auch nicht gleich gesehen - dass man beim Verwenden des XHR vorher festlegen muss, welchen responseType man erwartet und dann nur den Typ abfragen kann. Wenn man die Antwort nicht auf text oder json als kleinste gemeinsame Einheit herunterbrechen kann, hat man schlechte Karten.

dedlfix.

[pl]

Tach!

Es ist jetzt nur am Zuhörer, den Unterschied zwischen Trompetenspiel und Husten zu erkennen und dementsprechend die Darbietung zu genießen oder die Nase zu rümpfen.

Das Problem an der Stelle ist nur - und das hab ich auch nicht gleich gesehen - dass man beim Verwenden des XHR vorher festlegen muss, welchen responseType man erwartet und dann nur den Typ abfragen kann. Wenn man die Antwort nicht auf text oder json als kleinste gemeinsame Einheit herunterbrechen kann, hat man schlechte Karten.

Also ich finde, der kleinste gemeinsame Nenner ist der ArrayBuffer. Weil man dazu die Lib StringView ohnedies hinzunehmen muss, was die Methode .getString() mit sich bringt. So erstellt man aus der ganzen Response ein DataView und zieht mit StringView.getString() die Fehlermeldung raus, fertig.

Mit JSON hingegen hat man immer das Problem, daß die Fehlermeldung praktisch immer einen festen Platz in der gewählten Datenstruktur haben muss.

Aber ich wollt' ja auch mal wissen wie Andere das so handhaben.

MfG

[dedlfix]

Tach!

Also ich finde, der kleinste gemeinsame Nenner ist der ArrayBuffer. Weil man dazu die Lib StringView ohnedies hinzunehmen muss, was die Methode .getString() mit sich bringt.

StringView gibts nicht mehr im Browser.

Mit JSON hat man immer das Problem, daß die Fehlermeldung praktisch immer einen festen Platz in der gewählten Datenstruktur haben muss.

Nö, JSON und Javascript ist flexibel, da muss nichts vorhanden sein.

Aber ich wollt' ja auch mal wissen wie Andere das so handhaben.

Zwei Objekte, eins für den Gutfall, eins für den Fehlerfall. Unterscheidbar entweder über den Statuscode oder zur Not auch über eine Abfrage, ob bestimmte Felder im Inhalt vorhanden sind. if (deinResponseObjekt.error) { ...

dedlfix.

[pl]

Welcher Status ist denn so üblich diesbezüglich bei

1. Eingabefehler
2. Exception

zu senden?

MfG

[dedlfix]

Tach!

Welcher Status ist denn so üblich diesbezüglich bei

1. Eingabefehler

400

2. Exception

500

dedlfix.

[pl]

Tach!

Welcher Status ist denn so üblich diesbezüglich bei

1. Eingabefehler

400

2. Exception

500

Na, das ist doch mal ne Ansage 😉

FG und Danke.

[Rolf B]

Hallo pl,

aber nicht wirklich richtig. HTTP Statuscodes beschreiben die Erfolge der Transportschicht. Falsche Eingaben sind Sache der Anwendung (nicht zu verwechseln mit OSI Application Layer) und eine Fehlermeldung im Sinne von "Bitte als Gewicht maximal 130kg eingeben" ist meiner Überzeugung nach eine HTTP 200 Response.

10.4.1 400 Bad Request

   The request could not be understood by the server due to malformed
   syntax. The client SHOULD NOT repeat the request without
   modifications.

HTTP 400 müsste man schicken, wenn das Format der gelieferten Daten technisch nicht der Spec entspricht, z.B. die URL-Codierung des Post-Body falsch aufgebaut ist.

Ich gebe zu, das Thema ist ärgerlich; man möchte nicht HTTP 200 und OK senden, wenn es doch ein Error ist. Hier diskutieren sie auch drüber, jemand ist am Ende mit HTTP 422 nach Hause gegangen. Aber auch da hatte ich den Eindruck, dass es zu diesem Thema kein "so ist's gut" gab, sondern nur ein "das ist am wenigsten blöd".

Rolf

[dedlfix]

Tach!

aber nicht wirklich richtig.

Ja, bei der 400 hatte ich auch kein gutes Gefühl. Die 500 bei nicht behandelten Exceptions ist hingegen ziemlich klar.

HTTP Statuscodes beschreiben die Erfolge der Transportschicht. Falsche Eingaben sind Sache der Anwendung (nicht zu verwechseln mit OSI Application Layer) und eine Fehlermeldung im Sinne von "Bitte als Gewicht maximal 130kg eingeben" ist meiner Überzeugung nach eine HTTP 200 Response.

Wenn man mal ein normales Formular nimmt, dann antwortet man auch mit 200 und einer Seite, die eine Fehlermeldung nebst dem nochmal auszufüllenden Formular enthält. So müsste man das im Prinzip auch bei Ajax-Requests handhaben.

jemand ist am Ende mit HTTP 422 nach Hause gegangen

Die ist auch nicht so ganz klar, wohl eher für WebDAV gedacht. Am besten nimmt man da wohl die 418. Oder irgendeine unbenutzte Nummer.

Wenn man sich mal zur Abwechslung fetch() anschaut:

The Promise returned from fetch() won’t reject on HTTP error status even if the response is an HTTP 404 or 500. Instead, it will resolve normally (with ok status set to false), and it will only reject on network failure or if anything prevented the request from completing.

Das hat auch eine klare Meinung. Es ist immer erfolgreich, wenn der Server geantwortet hat. Das Bewerten des Inhalts der Antwort ist nicht mehr sein Thema. Trennung der Zuständigkeiten. Da muss man sich noch eine Schicht in die Architektur einziehen, wenn man das in Richtung der Anwendung anders und mehr aus ihrer Sicht kommunizieren möchte.

dedlfix.

[pl]

hi,

aber nicht wirklich richtig. HTTP Statuscodes beschreiben die Erfolge der Transportschicht.

Ein Bad Request hat nicht wirklich einen Bezug zur Transportschicht. Und ein 500er schon gar nicht. Siehe auch HTTP Spec.

Falsche Eingaben sind Sache der Anwendung

Ja sicher, unbedingt. Aber hier gehts ja darum welche Technik zur Kommunikation des Fehlers an den Benutzer zum Einsatz kommen könnte. Und das gehört schließlich auch zur Anwendung.

HTTP 400 müsste man schicken, wenn das Format der gelieferten Daten technisch nicht der Spec entspricht, z.B. die URL-Codierung des Post-Body falsch aufgebaut ist.

Für einen Benutzer sollte der Status eigentlich unsichtbar sein. Ebensowenig kriegt der Benutzer ein Bad Request zu sehen, sondern eine aussagekräftige Meldung und zwar möglichst in der Nähe des Buttons mit welchem er die Aktion ausgelöst hat.

Also ich nutze den HTTP Status ganz konsequent, er ist ja auch recht einfach abzufragen, programmiertechnisch also kein zusätzlicher Aufwand.

Wie machst Du das alles programmiertechnisch?

MfG

[Rolf B]

Hallo pl,

Erfolge der Transportschicht. Ein Bad Request hat nicht wirklich einen Bezug zur Transportschicht

Sorry, ich habe einen missverständlichen Begriff verwendet. Ich meinte nicht die OSI-Transportschicht, sondern den kompletten HTTP Stack, also den technischen Teil der Request/Response Übermittlung.

Gerade habe ich aber noch den hier gefunden, dort wird HTTP 400 für "domain validation errors" empfohlen - und das sind tatsächlich fachliche Fehler.

Wie machst Du das alles programmiertechnisch?

Die Dinge, die ich mit Webservices oder so beruflich programmiert habe, verwenden SOAP oder WCF (Windows Communication Foundation), da schirmt mich .net von den Nervigkeiten des HTTP Transports ab. Soweit ich weiß, liefert SOAP einen HTTP 200 und kommuniziert fachliche Fehler per Response-Inhalt. Was WCF bei einem Fault macht, weiß ich nicht; aber weil WCF ein Stack aus diversen Transportprotokollen ist, wo HTTP nur einer von vielen Bausteinen ist, kann ich mir vorstellen, dass man auch da möglichst wenig auf HTTP Statuscodes setzt.

Deswegen habe ich zum Thema zwar eine Meinung, wie ich es machen WÜRDE, aber keine direkte Berufserfahrung.

Rolf

[pl]

hi,

Gerade habe ich aber noch den hier gefunden, dort wird HTTP 400 für "domain validation errors" empfohlen - und das sind tatsächlich fachliche Fehler.

Ja, den Fehler kann man letztlich auch dem Client zuordnen nämlich wenn der seinen Rechner falsch konfiguriert hat.

Wie machst Du das alles programmiertechnisch?

Die Dinge, die ich mit Webservices oder so beruflich programmiert habe, verwenden SOAP oder WCF (Windows Communication Foundation), da schirmt mich .net von den Nervigkeiten des HTTP Transports ab. Soweit ich weiß, liefert SOAP einen HTTP 200 und kommuniziert fachliche Fehler per Response-Inhalt.

Also braucht man da grundsätzlich immer strukturierte Daten.

Deswegen habe ich zum Thema zwar eine Meinung, wie ich es machen WÜRDE, aber keine direkte Berufserfahrung.

Zweckmäßig und gleichzeitig einfach ist z.B. sowas:

    xhr.onload = function(){
        if(this.status != 200) {
            // Z.B. ein Popup für den Fehlertext
            pretext( this.response );
        }
        else{
            // Datenstruktur verarbeiten
        }
    };

Wobei der Popup als pretext(messagebody) noch dazu den Vorteil bietet, den Fehlertext so rüberzubringen wie er serverseitig formatiert wurde (Zeilenumrüche, Einrückungen..).

Für den legacy Betrieb habe ich da eine äquivalente Methode $self->pretext(); die genau dasselbe macht aber nicht als JS Popup sondern den Text an der richtigen Stelle ins Template setzt.

MfG

[pl]

hi,

Zwei Objekte, eins für den Gutfall, eins für den Fehlerfall. Unterscheidbar entweder über den Statuscode oder zur Not auch über eine Abfrage, ob bestimmte Felder im Inhalt vorhanden sind. if (deinResponseObjekt.error) { ...

Wobei bei einem status != 200 ein JSON gar keinen Sinn macht, weil da ohnehin nur eine Fehlermeldung zu erwarten ist.

MfG

[dedlfix]

Tach!

Wobei bei einem status != 200 ein JSON gar keinen Sinn macht, weil da ohnehin nur eine Fehlermeldung zu erwarten ist.

Und die darf man nicht zur besseren maschinellen Auswertung in eine JSON-Struktur packen wollen? Also ich sehe das als sinnvoll an.

dedlfix.

[pl]

Tach!

Wobei bei einem status != 200 ein JSON gar keinen Sinn macht, weil da ohnehin nur eine Fehlermeldung zu erwarten ist.

Und die darf man nicht zur besseren maschinellen Auswertung in eine JSON-Struktur packen wollen? Also ich sehe das als sinnvoll an.

Was soll denn auf dem Client da noch maschinell ausgewertet werden? Auf dem Client ist eine Fehlermeldung nur noch an den Benutzer zu kommunizieren. Maschinelle Abläufe hingegen finden auf dem Server statt: Da darf ein Fehler sogar zum Objekt werden was z.B. eine Methode hat zum Mailversand.

MfG

[dedlfix]

Tach!

Was soll denn auf dem Client da noch maschinell ausgewertet werden? Auf dem Client ist eine Fehlermeldung nur noch an den Benutzer zu kommunizieren. Maschinelle Abläufe hingegen finden auf dem Server statt: Da darf ein Fehler sogar zum Objekt werden was z.B. eine Methode hat zum Mailversand.

Du meinst also, dass die Ausführung von Javascript-Code kein maschineller Ablauf ist? Man kann SPAs schreiben, die hauptsächlich auf dem Client ablaufen. Da kann man sehr wohl die Notwendigkeit haben, mehr als lediglich einen Text als Information zur Verfügung zu haben, wenn beim Kommunizieren mit dem eigenen Server oder auch einem fremden Dienst Probleme auftauchen, um daraufhin auf die eine oder andere Weise zu reagieren.

Aber bleiben wir ruhig bei deinem Beispiel, dass der eigentliche Ablauf serverseitig stattfindet. Auch dann möchte ich gern dem Anwender detailliert mitteilen können, welche der Eingabefelder Fehler enthalten. Lediglich einen Text an zentraler Stelle anzuzeigen ist weniger nutzerfreundlich als die betroffenen Felder direkt zu markieren. Dazu brauch ich aber ein paar strukturierte Details, wie Meldungstext und dazu den Feldnamen.

dedlfix.

[1unitedpower]

hi,

Zwei Objekte, eins für den Gutfall, eins für den Fehlerfall. Unterscheidbar entweder über den Statuscode oder zur Not auch über eine Abfrage, ob bestimmte Felder im Inhalt vorhanden sind. if (deinResponseObjekt.error) { ...

Wobei bei einem status != 200 ein JSON gar keinen Sinn macht, weil da ohnehin nur eine Fehlermeldung zu erwarten ist.

Es könnten ja auch mehrere Fehler auftreten, die sich auf verschiedene Aspekte beziehen. Zum Beispiel können bei einer Formularvalidierung in diversen Feldern Fehler auftreten, dann wäre es praktisch, gleich alle Fehlermeldungen in der Antwort zu kodieren und den Feldern, die dafür gesorgt haben zuordnen zu können. Ein fiktives Beispiel:

{
    "formValidationErrors" : [
        {
            "type": "OutOfBoundsException",
            "fieldname": "age",
            "min": 0,
            "max": 100,
            "actual": 130,
            "message": "The field 'age' is expected to have a value between 0 and 100, but 130 was given",
        },
        {
            "type": "InvalidDateException",
            "fieldname": "birthdate",
            "actual": "29.02.1989",
            "message": "The field 'birthdate' expects a valid date, but the date '29.02.1989' doesn't exist.",
        },
    ],
    "serviceErrors": [
         {
             "type": "GeoLocationServiceTimeout",
             "threshold": 1,
             "message": "The GeoLocation-Server did not respond within 1s, we rescheduled the task to run again in 30 minutes. You can come back in half an hour to re-evaluate the response from the the GeoLocation-Server. Keep calm." 
         }
    ]
}

Die Fehler könntest du auch in einem benutzerdefiniertem Binärformat kodieren, nur musst du dir dann viel mehr Gedanken um die Kodierung machen und hättest am Ende eine Server-Antwort, die nicht mehr menschenlesbar und deshalb nicht mehr so einfach zu debuggen wäre.

[pl]

Genau!

Bestimmend für den Aufbau einer Datenstruktur ist nicht der Transport sondern die Verwendung.

MfG

[Robert B.]

Hallo pl,

Wobei bei einem status != 200 ein JSON gar keinen Sinn macht, weil da ohnehin nur eine Fehlermeldung zu erwarten ist.

ich sehe nicht, was an einem 3xx fehlerhaft sein soll.

Viele Grüße
Robert

[pl]

hi,

Wobei bei einem status != 200 ein JSON gar keinen Sinn macht, weil da ohnehin nur eine Fehlermeldung zu erwarten ist.

ich sehe nicht, was an einem 3xx fehlerhaft sein soll.

Es geht hier ums Prinzip. Aber Du kannst ja gerne mal ein Codebeispiel aus Deiner Praxis zeigen, das würde auch sehr gut hierher passen.

MfG

[Robert B.]

Moin,

wieso in die Ferne schweifen, wenn das Gute so nah ist.

Und wofür möchtest du jetzt ein Beispiel?

Viele Grüße
Robert

[pl]

hi @Robert B.

Und wofür möchtest du jetzt ein Beispiel?

Thema Fehlerbehandlung mit Ajax//Fetch.

Danke und Gruß

[Robert B.]

Hallo pl,

ein 2xx oder 3xx HTTP-Statuscode ist nicht nur für mich weder eine Exception noch ein Fehler.

Viele Grüße
Robert

[pl]

hi

ein 2xx oder 3xx HTTP-Statuscode ist nicht nur für mich weder eine Exception noch ein Fehler.

Dann sollte man auch keinen Status 2xx oder 3xx senden wenn ein Fehler konstatiert wurde.

MfG

[Robert B.]

Moin pl,

ein 2xx oder 3xx HTTP-Statuscode ist nicht nur für mich weder eine Exception noch ein Fehler.

Dann sollte man auch keinen Status 2xx oder 3xx senden wenn ein Fehler konstatiert wurde.

wer macht denn sowas? Zur Erinnerung: Mir ging es darum, dass nicht alle Statuscodes != 200 Fehler sind.

Viele Grüße
Robert

[beatovich]

Bedenke, responseType ist ein ArrayBuffer. Du müsstest also serverseitig die Fehlermeldung entsprechend verpacken und clientseitig aus dem ArrayBuffer über ein StringView den String in ein JSON umwandeln um dann aus dem JSON die Fehlermeldung zu ziehen. Das erscheint mir ziemlich umständlich 😉

Wenn dein Server einen ungeplanten Zustand erfährt und dann einen responseType ArrayBuffer sendet, dann manchst du definitiv logistisch etwas falsch auf dem Server. Du scheinst nämlich das fundamentale Prinzip Eingabe->Verarbeitung->Ausgabe zu verletzen.

[pl]

Bedenke, responseType ist ein ArrayBuffer. Du müsstest also serverseitig die Fehlermeldung entsprechend verpacken und clientseitig aus dem ArrayBuffer über ein StringView den String in ein JSON umwandeln um dann aus dem JSON die Fehlermeldung zu ziehen. Das erscheint mir ziemlich umständlich 😉

Wenn dein Server einen ungeplanten Zustand erfährt und dann einen responseType ArrayBuffer sendet, dann manchst du definitiv logistisch etwas falsch auf dem Server. Du scheinst nämlich das fundamentale Prinzip Eingabe->Verarbeitung->Ausgabe zu verletzen.

??? Jeder Text der gesendet wird ist ein ArrayBuffer 😉

[beatovich]

hallo

Bedenke, responseType ist ein ArrayBuffer. Du müsstest also serverseitig die Fehlermeldung entsprechend verpacken und clientseitig aus dem ArrayBuffer über ein StringView den String in ein JSON umwandeln um dann aus dem JSON die Fehlermeldung zu ziehen. Das erscheint mir ziemlich umständlich 😉

Wenn dein Server einen ungeplanten Zustand erfährt und dann einen responseType ArrayBuffer sendet, dann manchst du definitiv logistisch etwas falsch auf dem Server. Du scheinst nämlich das fundamentale Prinzip Eingabe->Verarbeitung->Ausgabe zu verletzen.

??? Jeder Text der gesendet wird ist ein ArrayBuffer 😉

Soll heissen? Der Client wird nur diesen responseType akzeptieren?

[pl]

hallo

Bedenke, responseType ist ein ArrayBuffer. Du müsstest also serverseitig die Fehlermeldung entsprechend verpacken und clientseitig aus dem ArrayBuffer über ein StringView den String in ein JSON umwandeln um dann aus dem JSON die Fehlermeldung zu ziehen. Das erscheint mir ziemlich umständlich 😉

Wenn dein Server einen ungeplanten Zustand erfährt und dann einen responseType ArrayBuffer sendet, dann manchst du definitiv logistisch etwas falsch auf dem Server. Du scheinst nämlich das fundamentale Prinzip Eingabe->Verarbeitung->Ausgabe zu verletzen.

??? Jeder Text der gesendet wird ist ein ArrayBuffer 😉

Soll heissen? Der Client wird nur diesen responseType akzeptieren?

Nein. responseType='arraybuffer' ist das was der Client verstehen will, also was er zur Verarbeitung einer Response beabsichtigt: Bytesemantic.

MfG

[beatovich]

hallo

Soll heissen? Der Client wird nur diesen responseType akzeptieren?

Nein. responseType='arraybuffer' ist das was der Client verstehen will, also was er zur Verarbeitung einer Response beabsichtigt: Bytesemantic.

Dann bring ihm im FehlerFall ein anderes Verhalten bei.

MfG

[klawischnigg]

Hi there

wie macht Ihr das eigentlich? Also wenn der Request am Server einen Fehler oder eine Exception wirft?

Dann hat der Anwender Pech gehabt. Fehlerbehandlung ist was für Feiglinge, Warmduscher und Frauenversteher…

[beatovich]

hallo

Guten Morgen, wie macht Ihr das eigentlich? Also wenn der Request am Server einen Fehler oder eine Exception wirft? Bitte mal um Inspirations. MfG

Bereinigen.

Es mag ungeplante Zustände geben, die man mit warn() loggen und als JSON auch an den Browser berichten kann. Deshalb gehört es zum Ersten, dass ich jeden Fall, der nicht meinen Erwartungen entspricht, durchaus weiterverarbeite im Sinne sinnvollen Informationsgeschehens. Deshalb testen alle xhr-responsehandler, ob das gelieferte JSON dem typ Errormessage entsprechen.

Als Admin möchte ich bereits im Browser vollen Zugriff auf das Servererrorlog haben. Errorreporting ist also von Zugriffsrechten abhängig.

[pl]

Hi,

es gibt ein Prinzip dem ich schon immer treu geblieben bin: Bestimmend für den Aufbau einer Datenstruktur ist nicht der Transport sondern die Verwendung.

Weil: Es sich bewährt hat. Das heißt mit anderen Worten, daß man für eine Fehlermeldung keinen JSON benötigt.

MfG