האתר הישראלי להנדסת תכנה

גילוי תקלות

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

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

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