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