Fehlerbehandlung bei Verwendung der Fetch API implementieren

Umar Hansa
Umar Hansa

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?
Aktion Der Nutzer beginnt, die falsche Videodatei hochzuladen. Nach dem Upload wählt der Nutzer dann die richtige Videodatei für den Upload aus.
Was passiert standardmäßig? Die Originaldatei wird im Hintergrund weiter hochgeladen, während gleichzeitig die neue Datei hochgeladen wird.
Was die Nutzer erwarten Der Nutzer erwartet, dass der ursprüngliche Upload beendet wird, damit keine zusätzliche Internetbandbreite verschwendet wird.
Was kann verbessert werden? JavaScript bricht die Abrufanfrage für die Originaldatei ab, bevor der Upload der neuen Datei beginnt.
Aktion Die Internetverbindung wird beim Hochladen des Videos unterbrochen.
Was passiert standardmäßig? Die Fortschrittsanzeige des Uploads bleibt bei 50 % stehen. Nach einer Weile kam es bei der Fetch API zu einer Zeitüberschreitung und die hochgeladenen Daten werden verworfen. Sobald wieder eine Internetverbindung besteht, muss der Nutzer die Datei noch einmal hochladen.
Was die Nutzer erwarten Der Nutzer erwartet, dass er benachrichtigt wird, wenn seine Datei nicht hochgeladen werden kann, und erwartet, dass der Upload automatisch bei 50% fortgesetzt wird, sobald er wieder online ist.
Was kann verbessert werden? Die Upload-Seite informiert den Nutzer über Probleme mit der Internetverbindung und versichert ihm, dass der Upload fortgesetzt wird, sobald die Internetverbindung wiederhergestellt ist.
Aktion Die Website zur Freigabe von Videos kann keinen Dateinamen mit einem Leerzeichen verarbeiten. Anstelle von „Meine Reisen.mp4“ werden Namen wie „Meine_Reisen.mp4“ oder „MeineReisen.mp4“ erwartet.
Was passiert standardmäßig? Der Nutzer muss warten, bis der Upload vollständig abgeschlossen ist. Sobald die Datei hochgeladen ist und in der Fortschrittsanzeige „100 %“ angezeigt wird, wird die folgende Meldung angezeigt: „Bitte versuchen Sie es noch einmal.“
Was die Nutzer erwarten Der Nutzer erwartet, dass er vor Beginn des Uploads oder zumindest innerhalb der ersten Sekunde des Uploads über die Dateinamenbeschränkungen informiert wird.
Was kann verbessert werden? Idealerweise unterstützt der Video-Sharing-Dienst Dateinamen mit Leerzeichen. Sie haben auch die Möglichkeit, den Nutzer vor dem Upload über Einschränkungen bei Dateinamen zu informieren. Alternativ sollte der Dienst zum Teilen von Videos den Upload mit einer detaillierten Fehlermeldung ablehnen.

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:

  1. Entfernen Sie das rotierende Ladesymbol von der Seite.
  2. Erklären Sie dem Nutzer, was schiefgelaufen ist und welche Möglichkeiten er hat.
  3. Zeigen Sie dem Nutzer je nach den verfügbaren Optionen die Schaltfläche „Noch einmal versuchen“.
  4. 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 von 200 bis 299 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.