In diesem Artikel werden einige Ansätze zur Fehlerbehandlung bei der Arbeit mit der Fetch API beschrieben. Mit der Fetch API können Sie eine Anfrage an eine Remote-Netzwerkressource stellen. Wenn Sie einen Remote-Netzwerkaufruf ausführen, kann Ihre Webseite mit einer Vielzahl potenzieller Netzwerkfehler behaftet sein.
In den folgenden Abschnitten werden mögliche Fehler beschrieben. Außerdem wird beschrieben, wie Sie Code schreiben, der eine sinnvolle Funktionalität bietet, die Fehlern und unerwarteten Netzwerkbedingungen standhält. Stabiler Code sorgt für zufriedene Nutzer und sorgt für ein standardmäßiges Serviceniveau für Ihre Website.
Potenzielle Netzwerkfehler vorhersehen
In diesem Abschnitt wird ein Szenario beschrieben, in dem der Nutzer ein neues Video mit dem Namen "My Travels.mp4"
erstellt und dann versucht, das Video auf eine Website zum Teilen von Videos hochzuladen.
Bei der Arbeit mit Fetch ist es einfach, den Happy Path zu berücksichtigen, auf dem der Nutzer das Video erfolgreich hochlädt. Es gibt jedoch andere Pfade, die nicht so reibungslos ablaufen, sondern für die Webentwickler planen müssen. Solche (unzufriedenen) Pfade können durch Nutzerfehler, unerwartete Umgebungsbedingungen oder einen Fehler auf der Website zum Teilen von Videos verursacht werden.
Beispiele für Nutzerfehler
- Der Nutzer lädt anstelle einer Videodatei eine Bilddatei (z. B. JPEG) hoch.
- Der Nutzer beginnt, die falsche Videodatei hochzuladen. Nach dem Upload wählt der Nutzer dann die richtige Videodatei für den Upload aus.
- Der Nutzer klickt beim Hochladen des Videos versehentlich auf „Upload abbrechen“.
Beispiele für Umweltveränderungen
- Die Internetverbindung wird unterbrochen, während das Video hochgeladen wird.
- Der Browser wird neu gestartet, während das Video hochgeladen wird.
- Die Server der Website zum Teilen von Videos starten während des Video-Uploads neu.
Beispiele für Fehler auf der Website zum Teilen von Videos
- Die Website zur Freigabe von Videos kann keinen Dateinamen mit einem Leerzeichen verarbeiten. Anstelle von
"My Travels.mp4"
wird ein Name wie"My_Travels.mp4"
oder"MyTravels.mp4"
erwartet. - Die Website zur Freigabe von Videos darf kein Video hochladen, das die maximal zulässige Dateigröße überschreitet.
- Die Website zum Teilen von Videos unterstützt den Video-Codec im hochgeladenen Video nicht.
Diese Beispiele können und tun es auch in der Praxis. Vielleicht sind Sie schon einmal in der Vergangenheit auf solche Beispiele gestoßen! Lassen Sie uns jeweils ein Beispiel aus den vorherigen Kategorien auswählen und die folgenden Punkte besprechen:
- Was ist die Standardeinstellung, wenn der Video-Sharing-Dienst das gegebene Beispiel nicht verarbeiten kann?
- Was erwartet die Nutzenden im Beispiel?
- Wie können wir den Prozess verbessern?
Fehler mit der Fetch API verarbeiten
In den folgenden Codebeispielen wird die await
der obersten Ebene (Browserunterstützung) verwendet, da diese Funktion Ihren Code vereinfachen kann.
Wenn die Fetch API Fehler ausgibt
In diesem Beispiel wird eine try
/catch
-Anweisung verwendet, um alle Fehler abzufangen, die im try
-Block ausgegeben werden. Wenn die Fetch API beispielsweise die angegebene Ressource nicht abrufen kann, wird ein Fehler ausgegeben. Achten Sie innerhalb eines catch
-Blocks wie diesem darauf, eine sinnvolle Nutzererfahrung zu bieten. Wenn dem Nutzer ein rotierendes Ladesymbol – eine gängige Benutzeroberfläche, die eine Art Fortschritt darstellt – angezeigt wird, können Sie innerhalb eines catch
-Blocks die folgenden Aktionen ausführen:
- Entfernen Sie das rotierende Ladesymbol von der Seite.
- Erklären Sie dem Nutzer, was schiefgelaufen ist und welche Möglichkeiten er hat.
- Zeigen Sie dem Nutzer je nach den verfügbaren Optionen die Schaltfläche „Noch einmal versuchen“.
- Senden Sie die Fehlerdetails im Hintergrund an Ihren Fehlerverfolgungsdienst oder an das Backend. Dadurch wird der Fehler protokolliert, damit er später diagnostiziert werden kann.
try {
const response = await fetch('https://website');
} catch (error) {
// TypeError: Failed to fetch
console.log('There was an error', error);
}
Während Sie den protokollierten Fehler später diagnostizieren, können Sie einen Testlauf schreiben, um einen solchen Fehler abzufangen, bevor Nutzer merken, dass etwas nicht stimmt. Je nach Fehler kann der Test ein Einheiten-, Integrations- oder Akzeptanztest sein.
Wenn der Netzwerkstatuscode einen Fehler darstellt
In diesem Codebeispiel wird eine Anfrage an einen HTTP-Testdienst gestellt, der immer mit dem HTTP-Statuscode 429 Too Many Requests
antwortet. Interessanterweise erreicht die Antwort den catch
-Block nicht. Der Status 404 gibt neben bestimmten anderen Statuscodes keinen Netzwerkfehler zurück, sondern wird normal behoben.
Sie können eine der folgenden Optionen verwenden, um zu überprüfen, ob der HTTP-Statuscode erfolgreich war:
- Verwenden Sie das Attribut
Response.ok
, um festzustellen, ob sich der Statuscode im Bereich von200
bis299
befand. - Mit dem Attribut
Response.status
kannst du feststellen, ob die Antwort erfolgreich war. - Verwenden Sie beliebige andere Metadaten wie
Response.headers
, um festzustellen, ob die Antwort erfolgreich war.
let response;
try {
response = await fetch('https://httpbin.org/status/429');
} catch (error) {
console.log('There was an error', error);
}
// Uses the 'optional chaining' operator
if (response?.ok) {
console.log('Use the response here!');
} else {
console.log(`HTTP Response Code: ${response?.status}`)
}
Es hat sich bewährt, mit Personen in Ihrem Unternehmen und Ihrem Team zusammenzuarbeiten, um mögliche Statuscodes der HTTP-Antwort zu verstehen. Backend-Entwickler, Developer Operations und Service Engineers können manchmal einzigartige Einblicke in mögliche Grenzfälle geben, die Sie möglicherweise nicht erwartet haben.
Wenn beim Parsen der Netzwerkantwort ein Fehler auftritt
Dieses Codebeispiel zeigt einen anderen Fehlertyp, der beim Parsen eines Antworttexts auftreten kann. Die Response
-Schnittstelle bietet praktische Methoden zum Parsen verschiedener Datentypen wie Text oder JSON. Im folgenden Code wird eine Netzwerkanfrage an einen HTTP-Testdienst gestellt, der einen HTML-String als Antworttext zurückgibt. Es wird jedoch versucht, den Antworttext als JSON zu parsen, wodurch ein Fehler ausgegeben wird.
let json;
try {
const response = await fetch('https://httpbin.org/html');
json = await response.json();
} catch (error) {
if (error instanceof SyntaxError) {
// Unexpected token < in JSON
console.log('There was a SyntaxError', error);
} else {
console.log('There was an error', error);
}
}
if (json) {
console.log('Use the JSON here!', json);
}
Sie müssen Ihren Code so vorbereiten, dass er verschiedene Antwortformate unterstützt, und sicherstellen, dass eine unerwartete Antwort die Webseite für den Nutzer nicht beeinträchtigt.
Stellen Sie sich folgendes Szenario vor: Sie haben eine Remoteressource, die eine gültige JSON-Antwort zurückgibt, und sie wird erfolgreich mit der Methode Response.json()
geparst. Es kann vorkommen, dass ein Dienst ausfällt. Nach dem Absturz wird ein 500 Internal Server Error
-Element zurückgegeben. Wenn beim Parsen von JSON keine geeigneten Methoden zur Fehlerbehandlung verwendet werden, kann dies die Seite für den Nutzer beschädigen, da ein unbehandelter Fehler ausgegeben wird.
Wenn die Netzwerkanfrage abgebrochen werden muss, bevor sie abgeschlossen wird
In diesem Codebeispiel wird ein AbortController
verwendet, um eine laufende Anfrage abzubrechen. Eine in Bearbeitung befindliche Anfrage ist eine Netzwerkanfrage, die gestartet, aber noch nicht abgeschlossen ist.
Die Szenarien, in denen Sie eine laufende Anfrage abbrechen müssen, können variieren, hängt aber letztendlich von Ihrem Anwendungsfall und Ihrer Umgebung ab. Der folgende Code zeigt, wie ein AbortSignal
an die Fetch API übergeben wird. Das AbortSignal
ist an eine AbortController
angehängt und die AbortController
enthält eine abort()
-Methode, die dem Browser signalisiert, dass die Netzwerkanfrage abgebrochen werden soll.
const controller = new AbortController();
const signal = controller.signal;
// Cancel the fetch request in 500ms
setTimeout(() => controller.abort(), 500);
try {
const url = 'https://httpbin.org/delay/1';
const response = await fetch(url, { signal });
console.log(response);
} catch (error) {
// DOMException: The user aborted a request.
console.log('Error: ', error)
}
Fazit
Ein wichtiger Aspekt beim Umgang mit Fehlern besteht darin, die verschiedenen Teile zu definieren, die schiefgehen können. Stellen Sie für jedes Szenario sicher, dass Sie eine geeignete Alternative für den Nutzer haben. Stellen Sie sich im Hinblick auf eine Abrufanfrage folgende Fragen:
- Was passiert, wenn der Zielserver ausfällt?
- Was passiert, wenn Abruf eine unerwartete Antwort erhält?
- Was passiert, wenn die Internetverbindung eines Nutzers fehlschlägt?
Je nach Komplexität Ihrer Webseite können Sie auch ein Flussdiagramm skizzieren, das die Funktionalität und Benutzeroberfläche für verschiedene Szenarien beschreibt.