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