"המחשב מאפשר לך לבצע טעויות מהר יותר מכל המצאה אחרת, אולי חוץ מאקדחים וטקילה." (מיטץ' רטקליף)

 

בתחילת שנות ה-90, כאשר הייתי עסוק בללמד את עצמי QBasic הודעות שגיאה טיפוסיות היו משהו כמו "Error 53" או "Error 13". הסיבה ההיסטורית לקצרנות הזו היא שבתחילת ימי המחשוב, זיכרון היה רכיב יקר מאד, ולכן מתכנתים ניסו לקצר הודעות שגיאה פשוט כדי לחסוך זיכרון (וכסף). כמה חבל שהודעות שגיאה רבות נבעו אז ממחסור בזיכרון…

 

היום, תודות לחוק מור, זיכרון הוא כבר כמעט ולא מהווה בעיה, ולכן אפשר ואולי אף הגיע הזמן לפרט מעט יותר. למרות זאת, עוד יוצא לי להיתקל מדי פעם בהודעות שגיאה ארכאיות אלו, החלק המרגיז באמת הוא שלמרות ש-Dot Net Framework מאפשרת לתוכניתן לייצר הודעות כל כך מועילות ואינפורמטיביות, עדיין אפשר להיתקל בכל כך הרבה מערכות מבוססות Dot Net אשר מתכנתיהן העדיפו להציג הודעות שגיאה קצרצרות (אשר חלק יגידו כי הן יפות למראה).

אם כך, מה צריכה לכלול הודעת שגיאה? הנה כמה המלצות לנושאים שחייבים להופיע בהודעת שגיאה על מנת לשמור על שפיות אנשי ה-HelpDesk כאשר הם נדרשים לפתור בעיה בתוכנה:

1. התמקד בבעיה, לא בפתרון: כאשר מתגלה שגיאה, הסבר בדיוק מה התוכנית עשתה או ניסתה לבצע, מה היה הקלט האחרון בו נתקלה המערכת וכו'. מערכות רבות מנסות להציע פתרון כגון "Please restart your computer" או "Contact your system administrator", אני סבור שהתוכניתן יכול בקושי לחזות את הסיבות שיגרמו למערכת שפיתח לקרוס או להשתבש, כך שזה ברור שזה יהיה כמעט בלתי אפשרי עבור התוכניתן להחליט על הפתרון לפני שהבעיה נותחה במלואה.לכן, לדעתי התכניתן צריך להתמקד בדברים שהוא יודע שהוא חייב לדעת במקרה של תקלה: מה התוכנית שלו ביצעה בכל שלב ושלב.

2. איפה (באיזה שלב) זה קרה: ציין תמיד את שם המודול/רכיב ושם הפונקציה או המתודה שבה השגיאה הופיעה. נתון זה עשוי להישמע מיותר למדי, אך אם בסופו של דבר יתברר שהשגיאה הזו מקורה ב"באג" תוכנתי (כפי שזה קורה פעמים רבות) נתון זה יהיה נחוץ ביותר עבורך על מנת לאתר את מיקום הבאג. באופן אישי, אני, תמיד דואג להוסיף את כל ה-Stack trace (באפליקציות dot net) להודעת השגיאה, זה יכול לסייע לטכנאים לקבל מושג לגבי מקור התקלה. במערכות רבות שפיתחתי ניתן למצוא משתנה גלובאלי מעניין בשם pos אני דואג לעדכן את ערכו של משתנה זה לתיאור קצרצר של הפעולה הבאה שהתוכנית עומדת לבצע, כמובן אני לא משנה אותו לפני כל שורת קוד אבל לפני כל בלוק פקודות המהווה פעולה מסויימת אחת, בדומה להגדרת הערות בקוד. כחלק מבלוק ה-"try-catch" אני משרשר את ערכו להודעת השגיאה, כך אני מסוגל למקד את עצמי לגבי מה בדיוק המערכת ניסתה לעשות כאשר השגיאה אירעה.

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

היות והודעות השגיאה לא נועדו למשתמש הקצה (מבחינתנו אין שום מניעה שלא יופיעו שגיאות בכלל, נכון?) אלא עבור טכנאי ה-HelpDesk או התוכניתן, הודעות אלו צריכות להיות משהו שהם יכולים לעבוד איתו.

אם תיישם את הטיפים הללו במערכת אותה אתה מפתח, אני בטוח שתחסוך זמן Troubleshooting רב כאשר הבאג הראשון יציץ ויראה את פרצופו המכוער…

השאר תגובה