מאמר זה מדגים כמה גישות לטיפול בשגיאות כשעובדים עם Fetch API. ה-API של שליפה מאפשר לך לשלוח בקשה למשאב של רשת מרוחקת. כשמבצעים שיחת רשת מרוחקת, דף האינטרנט עשוי להיות כפוף למגוון שגיאות רשת פוטנציאליות.
הקטעים הבאים מתארים שגיאות אפשריות ומתארים כיצד לכתוב קוד שמספק רמה הגיונית של פונקציונליות שעמידה בפני שגיאות ותנאי רשת לא צפויים. קוד גמיש שומר על שביעות רצון המשתמשים ושומר על רמת שירות סטנדרטית עבור האתר שלך.
חיזוי של שגיאות רשת פוטנציאליות
בקטע הזה מתואר תרחיש שבו משתמש יוצר סרטון חדש בשם "My Travels.mp4"
ואז מנסה להעלות את הסרטון לאתר לשיתוף סרטונים.
כשעובדים עם 'אחזור', קל לחשוב על הנתיב המאושר שבו המשתמש מעלה את הסרטון בהצלחה. עם זאת, יש נתיבים אחרים שאינם חלקים מאוד, אבל עבורם מפתחי אתרים צריכים לתכנן. נתיבים (לא מרוצים) כאלה יכולים לקרות עקב שגיאת משתמש, עקב תנאים סביבתיים לא צפויים או עקב באג באתר שיתוף הסרטונים.
דוגמאות לשגיאות משתמשים
- המשתמש מעלה קובץ תמונה (כגון JPEG) במקום קובץ וידאו.
- המשתמש מתחיל להעלות את קובץ הווידאו הלא נכון. לאחר מכן, במהלך ההעלאה, המשתמש מציין את קובץ הסרטון הנכון להעלאה.
- המשתמש לוחץ בטעות על "ביטול ההעלאה" בזמן העלאת הסרטון.
דוגמאות לשינויים סביבתיים
- החיבור לאינטרנט מתנתק כשמעלים את הסרטון.
- הדפדפן יופעל מחדש במהלך העלאת הסרטון.
- השרתים של אתר שיתוף הסרטונים מופעלים מחדש בזמן העלאת הסרטון.
דוגמאות לשגיאות באתר שיתוף הסרטונים
- אתר שיתוף הסרטונים לא יכול לטפל בשם קובץ עם רווח. במקום
"My Travels.mp4"
, הוא מצפה לשם כגון"My_Travels.mp4"
או"MyTravels.mp4"
. - אתר שיתוף הסרטונים אינו יכול להעלות סרטון שגודלו חורג מגודל הקובץ המרבי המותר.
- אתר שיתוף הסרטון אינו תומך ב-codec הווידאו שנכלל בסרטון שהועלה.
הדוגמאות האלה יכולות להתקיים בעולם האמיתי. יכול להיות שנתקלת בדוגמאות כאלה בעבר. נבחן דוגמה אחת מכל אחת מהקטגוריות הקודמות ונדון בנקודות הבאות:
- מהי התנהגות ברירת המחדל אם שירות שיתוף הווידאו לא יכול לטפל בדוגמה הנתונה?
- מה המשתמש מצפה שיקרה בדוגמה?
- איך נוכל לשפר את התהליך?
טיפול בשגיאות באמצעות Fetch API
לתשומת ליבכם, בדוגמאות הבאות לקוד נעשה שימוש ברמה העליונה await
(תמיכה בדפדפנים), כי התכונה הזו יכולה לפשט את הקוד.
כאשר ה-API של אחזר שולח שגיאות
הדוגמה הזו משתמשת בהצהרת try
/catch
בלוק כדי לאתר שגיאות שהתקבלו בבלוק try
. לדוגמה, אם ה-API של אחזור אינו יכול לאחזר את המשאב שצוין, תתקבל הודעת שגיאה. בתוך בלוק catch
כזה, חשוב לספק חוויית משתמש משמעותית. אם מוצג למשתמש סימן גרפי מסתובב, ממשק משתמש נפוץ שמייצג התקדמות כלשהי, תוכלו לבצע את הפעולות הבאות בתוך בלוק catch
:
- מסירים את הסימן הגרפי שמופיע בדף.
- אפשר להעביר מסרים מועילים שמסבירים מה השתבש ואילו אפשרויות המשתמש יכול לבצע.
- בהתאם לאפשרויות הזמינות, מציגים למשתמש לחצן 'ניסיון חוזר'.
- מאחורי הקלעים, שולחים את פרטי השגיאה לשירות מעקב אחר שגיאות או לקצה העורפי. הפעולה הזו מתעדת את השגיאה כדי שניתן יהיה לאבחן אותה בשלב מאוחר יותר.
try {
const response = await fetch('https://website');
} catch (error) {
// TypeError: Failed to fetch
console.log('There was an error', error);
}
בשלב מאוחר יותר, בזמן שאתם מאבחנים את השגיאה שרשמתם, אתם יכולים לכתוב בקשת בדיקה כדי לזהות שגיאה כזאת לפני שהמשתמשים ידעו שמשהו השתבש. בהתאם לשגיאה, הבחינה יכולה להיות יחידת מודעות, בדיקת שילוב או קבלה.
כשקוד סטטוס הרשת מייצג שגיאה
בדוגמת הקוד הזו, נשלחת בקשה לשירות בדיקה של HTTP שמגיב תמיד עם קוד הסטטוס של HTTP 429 Too Many Requests
. מעניין שהתגובה לא מגיעה לבלוק catch
. סטטוס 404, בין חלק מקודי הסטטוס האחרים, אינו מחזיר שגיאת רשת אלא נפתר כרגיל.
כדי לבדוק אם קוד מצב ה-HTTP בוצע בהצלחה, אפשר להשתמש בכל אחת מהאפשרויות הבאות:
- המאפיין
Response.ok
מאפשר לקבוע אם קוד הסטטוס היה בטווח בין200
ל-299
. - אפשר להשתמש במאפיין
Response.status
כדי לבדוק אם התגובה הצליחה. - להשתמש במטא-נתונים אחרים, כמו
Response.headers
, כדי להעריך אם התשובה הצליחה.
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}`)
}
השיטה המומלצת היא לעבוד עם אנשים בארגון ובצוות שלכם כדי להבין את קודי הסטטוס הפוטנציאליים של תגובת HTTP. לפעמים מפתחי קצה עורפי, תפעול מפתחים ומהנדסי שירות יכולים לספק תובנות ייחודיות לגבי מקרי קצה אפשריים שלא היית מצפה להם.
כשיש שגיאה בניתוח תגובת הרשת
דוגמת הקוד הזו ממחישה סוג אחר של שגיאה שעלולה להתעורר במהלך ניתוח גוף התגובה. בממשק Response
יש שיטות נוחות לניתוח סוגים שונים של נתונים, כמו טקסט או JSON. בקוד הבא, נשלחת בקשת רשת לשירות בדיקת HTTP שמחזיר מחרוזת HTML כגוף התגובה. עם זאת, יתבצע ניסיון לנתח את גוף התגובה כ-JSON ובעקבות זאת תוצג שגיאה.
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);
}
צריך להכין את הקוד כך שיפעל במגוון פורמטים של תגובות, ולוודא שתגובה בלתי צפויה לא קוטעת את דף האינטרנט מבחינת המשתמש.
שימו לב לתרחיש הבא: יש לכם משאב מרוחק שמחזיר תגובת JSON תקינה, והוא מנותח בהצלחה באמצעות השיטה Response.json()
. ייתכן שהשירות יופסק. אחרי הירידה, מוחזר 500 Internal Server Error
. אם לא משתמשים בשיטות מתאימות לטיפול בשגיאות במהלך ניתוח JSON, הדף עלול להיקטע עבור המשתמש בגלל שגיאה שלא טופלה.
מתי צריך לבטל את בקשת הרשת לפני שהיא מסתיימת
בדוגמה הזו לקוד נעשה שימוש ב-AbortController
כדי לבטל בקשה פעילה. בקשה פעילה היא בקשת רשת שהתחילה אך לא הושלמה.
התרחישים שבהם ייתכן שתצטרכו לבטל בקשה פעילה עשויים להשתנות, אבל בסופו של דבר תלויים בתרחיש לדוגמה ובסביבה שלכם. הקוד הבא מדגים איך להעביר AbortSignal
ל-Fetch API. ה-AbortSignal
מצורף אל AbortController
וה-AbortController
כולל שיטה abort()
שמציינת לדפדפן שצריך לבטל את בקשת הרשת.
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)
}
סיכום
היבט חשוב אחד בטיפול בשגיאות הוא הגדרת החלקים השונים שעלולים להשתבש. בכל תרחיש, חשוב לוודא שיש למשתמש חלופה מתאימה. בנוגע לבקשת אחזור, כדאי לשאול את עצמכם שאלות כמו:
- מה קורה אם שרת היעד מושבת?
- מה קורה אם אחזור מקבל תגובה בלתי צפויה?
- מה קורה אם החיבור של המשתמש לאינטרנט נכשל?
בהתאם למורכבות דף האינטרנט שלכם, תוכלו גם לשרטט תרשים זרימה שמתאר את הפונקציונליות ואת ממשק המשתמש של תרחישים שונים.