try/catch ב-JavaScript: טיפול בשגיאות בלי קריסות

try/catch הוא רשת ביטחון, לא חגורת בטיחות

כששורה של JavaScript זורקת שגיאה, הביצוע נעצר במקום והשגיאה מתפשטת למעלה במחסנית הקריאות. אם שום דבר לא תופס אותה, התוכנית קורסת (ב-Node) או מדפיסה קיר אדום בקונסול (בדפדפנים). try/catch הוא הדרך ליירט את זה, כלומר לומר "אני יודע שזה עלול להיכשל, הנה מה שאני רוצה לעשות במקום".

הצורה הבסיסית:

try {
  const data = JSON.parse('{ not valid json');
  console.log(data);
} catch (err) {
  console.log("לא הצלחנו לפענח:", err.message);
}

console.log("התוכנית ממשיכה");

JSON.parse זורק SyntaxError. הביצוע קופץ מיד לבלוק ה-catch, כשהשגיאה קשורה ל-err. ה-console.log השלישי עדיין רץ: הקריסה נבלמה.

אם בלוק ה-try מצליח בלי לזרוק, מדלגים לגמרי על בלוק ה-catch. הוא שם בשביל מסלול הכישלון.

אובייקט השגיאה

כל מה שנזרק נקשר לשם הפרמטר ב-catch (...). בדרך כלל זה מופע של Error עם שלושה שדות שימושיים:

try {
  null.foo;
} catch (err) {
  console.log(err.name);     // TypeError
  console.log(err.message);  // Cannot read properties of null...
  console.log(err.stack);    // ה-stack trace המלא
}

name אומר לכם מהי תת-המחלקה (TypeError, RangeError, SyntaxError וכו', עוד עליהן במסמך הבא). message הוא התיאור הקריא לבני אדם. stack הוא העקבות המלאים, ששווים זהב בזמן דיבוג.

מלכודת אחת: JavaScript מאפשרת לזרוק כל דבר עם throw, לא רק אובייקטים של Error. קוד ישן עושה לפעמים throw "something broke". כשאתם כותבים throw משלכם, זרקו תמיד Error כדי שהקוד שקורא לכם יקבל stack trace:

function divide(a, b) {
  if (b === 0) throw new Error("חלוקה באפס");
  return a / b;
}

try {
  divide(10, 0);
} catch (err) {
  console.log(err.message);
}

finally רץ בכל מקרה

finally הוא בלוק שלישי אופציונלי שרץ בין אם נזרקה שגיאה ובין אם לא, ובין אם ה-catch טיפל בה ובין אם לא. הוא נועד לניקוי: סגירת קבצים, שחרור נעילות, הסתרת אנימציות טעינה:

function loadUser() {
  console.log("הצגת spinner");
  try {
    throw new Error("הרשת נפלה");
  } catch (err) {
    console.log("טופל:", err.message);
  } finally {
    console.log("הסתרת spinner");
  }
}

loadUser();

ה-spinner מוסתר בין אם הטעינה הצליחה ובין אם נכשלה. בלי finally, הייתם צריכים לכתוב את השורה הזו בשני הענפים, ולשכוח אותה באחד מהם.

finally רץ אפילו אם בלוק ה-try או ה-catch מכיל return. הפונקציה מחזירה ערך אחרי ש-finally רץ. לפעמים זה מפתיע; ברוב המקרים זה בדיוק מה שרוצים.

לא תמיד צריך catch

catch הוא אופציונלי. try/finally לבד הוא חוקי ושימושי כשרוצים ניקוי מובטח אבל אין שום כוונה לטפל בשגיאה: רוצים שהיא תתפשט הלאה:

function withLock(fn) {
  console.log("נעילה");
  try {
    return fn();
  } finally {
    console.log("שחרור הנעילה");
  }
}

try {
  withLock(() => { throw new Error("boom"); });
} catch (err) {
  console.log("הקוד הקורא ראה:", err.message);
}

ה-try/finally הפנימי משחרר את הנעילה גם כש-fn() זורק, אבל לא בולע את השגיאה: הקוד הקורא עדיין רואה אותה. בליעת שגיאות בשקט ("זה נכשל ולא סיפרתי לאף אחד") היא אחד מסיוטי הדיבוג הנפוצים ביותר.

זריקה מחדש: לטפל בחלק, להעביר את השאר הלאה

בלוק catch לא חייב לטפל בהכול. אפשר לבחון את השגיאה, לטפל במה שהגיוני ולזרוק מחדש את השאר:

function readConfig(raw) {
  try {
    return JSON.parse(raw);
  } catch (err) {
    if (err instanceof SyntaxError) {
      console.log("הגדרות לא תקינות, משתמשים בברירות מחדל");
      return { theme: "light" };
    }
    throw err;
  }
}

console.log(readConfig('{"theme":"dark"}'));
console.log(readConfig("not json"));

בדיקת ה-instanceof היא הדפוס: לזהות את השגיאות שאתם יודעים להתאושש מהן, ולתת לכל השאר להמשיך במעלה המחסנית. בליעת כל שגיאה עם בלוק catch ריק היא סימן לקוד בעייתי: מאבדים כל אות כשמשהו לא צפוי משתבש.

try/catch עם async/await

בתוך פונקציית async, promises שעושים להם await ונדחים הופכים לשגיאות שנזרקות, ו-try/catch מטפל בהן בדיוק כמו בשגיאות סינכרוניות:

async function getUser(id) {
  try {
    const res = await fetch(`https://api.example.com/users/${id}`);
    if (!res.ok) throw new Error(`HTTP ${res.status}`);
    return await res.json();
  } catch (err) {
    console.log("fetch failed:", err.message);
    return null;
  }
}

getUser(1).then(u => console.log(u));

דקות אחת: חייבים לעשות await ל-promise בתוך בלוק ה-try. אם מחזירים promise בלי await, הדחייה קורית אחרי שהפונקציה כבר יצאה, וה-catch אף פעם לא רואה אותה:

async function bad() {
  try {
    return fetch("/broken");  // no await - caller sees the rejection
  } catch (err) {
    // never runs
  }
}

כלל אצבע: בפונקציות async, עשו await לדבר שאתם רוצים ש-try/catch יכסה.

try/catch מקונן

אפשר לקנן בלוקים של try/catch כשהקוד הפנימי והחיצוני נכשלים מסיבות שונות שרוצים לטפל בהן אחרת:

function processPayload(raw) {
  try {
    const data = JSON.parse(raw);
    try {
      return data.items.map(item => item.toUpperCase());
    } catch (err) {
      return [];
    }
  } catch (err) {
    throw new Error("invalid payload: " + err.message);
  }
}

console.log(processPayload('{"items":["a","b"]}'));
console.log(processPayload('{"items":[1,2]}'));

ה-catch הפנימי מטפל ב"מבנה הנתונים שגוי" על ידי החזרת ברירת מחדל בטוחה. החיצוני מטפל ב"הקלט בכלל לא היה JSON" על ידי עטיפה וזריקה מחדש. קינון זה בסדר כשלכל שכבה יש אסטרטגיית התאוששות נפרדת. אם שני הבלוקים היו עושים את אותו הדבר, שטחו אותם.

מתי לא להשתמש ב-try/catch

try/catch הוא כלי לכישלונות צפויים שאפשר להתאושש מהם. הוא לא דרך לטייח באגים.

• אל תעטפו גוף שלם של פונקציה "ליתר ביטחון". אם אין לכם תוכנית אמיתית לשגיאה, תנו לה לבעבע למעלה: שגיאה שלא נתפסה עם stack trace שימושית יותר משגיאה שקטה.
• אל תשתמשו בו לבקרת זרימה. לבלוקים של try יש תקורה אמיתית והם מערפלים את הקוד לעומת בדיקת if. if (user) עדיף על try { user.name } catch {}.
• אל תתפסו, תרשמו ללוג ותתעלמו. לכל הפחות, זרקו מחדש או החזירו ערך מיוחד שהקוד הקורא יכול לזהות.

המבחן המחשבתי: "מה עושה מי שמשתמש בקוד הזה כשהוא נכשל?" אם אין לכם תשובה, אתם עוד לא מוכנים לתפוס את השגיאה עם catch.

טבלת עזר מהירה

• try { ... } catch (err) { ... }: יירוט שגיאות שנזרקות.
• finally { ... }: תמיד רץ; השתמשו בו לניקוי.
• throw new Error("..."): זרקו תמיד תת-מחלקות של Error כדי ש-stack traces יעבדו.
• throw err; בתוך catch: זריקה מחדש כשאי אפשר לטפל בשגיאה.
• await בתוך try: הכרחי כדי ש-try/catch יראה דחיות אסינכרוניות.

הבא בתור: סוגי שגיאות

TypeError, RangeError, SyntaxError: ל-JavaScript יש משפחה של מחלקות שגיאה מובנות, והיכרות עם המשמעות של כל אחת הופכת את התפיסה והדיווח למדויקים הרבה יותר. זה המסמך הבא.