טיפול בחריגות - Exception Handling
Convert.ToInt32 שמקבל את הקלט abc.throw.Exception או נגזרת שלו. כדאי לזרוק את החריגה המדויקת ביותר, למשל ArgumentNullException כשהמערך הוא null, ו-ArgumentException כשהוא ריק.getAverage מקבלת מערך ריק. במקום לחלק באפס ולקבל אינסוף, היא זורקת חריגה עם הודעה מתאימה.catch כללי מסוג Exception חייב לבוא אחרון, כי הוא תופס הכול.return בתוך try או catch. לכן מתאים לשחרור משאבים.Exception. לדוגמה, IllegalGradeException נזרקת בתוך ה-set של ציון שאינו בין 0 ל-100. מי שמשתמש במחלקה יכול לתפוס בדיוק את הבעיה הזאת, ולהציג הודעה ברורה במקום קריסה. כעת אפשר לכתוב קוד שמזהה קלט לא חוקי, מעלה חריגה מדויקת, ומטפל בה בלי שהתוכנית תיפול.פרקי ההרצאה: טיפול בחריגות - Exception Handling
תמלול ההרצאה: טיפול בחריגות - Exception Handling
הטקסט המלא של הדקות הראשונות בהרצאה «טיפול בחריגות - Exception Handling» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אנחנו מגיעים לנושא סופר חשוב בעולם פיתוח התוכנה שבעצם קיים בכל תוכנית שאנחנו כותבים. הנושא הזה אנחנו יכולים לראות אותו עכשיו רק אחרי שאנחנו באמת מבינים Object Oriented והנושא הזה נקרא Exception Handling, כלומר טיפול בחריגות.
קודם כל, מה זה חריגה? חריגה זה שגיאה שמתרחשת במהלך הריצה שגורמת לתוכנית לקרוס. למעשה יש בעולם הפיתוח תוכנה שלושה סוגים של שגיאות.
סוג ראשון נקרא שגיאת קומפילציה. נניח שאנחנו פותחים פה int x שווה 8 ומריצים את התוכנית. אז אנחנו באים להריץ את התוכנית או לבנות ממנה קובץ Execution ואנחנו רואים שהתוכנית כותבת לנו נקודה פסיק אקספקטד.
אז השגיאה הזאת זה כמובן שגיאה שהתרחשה אבל היא לא התרחשה במהלך הריצת התוכנית, היא התרחשה במהלך הקומפילציה כלומר התהליך שבו visual studio או יותר נכון מנגנון הקומפיילר קורא את הקוד שלנו ומנסה ליצור ממנו קובץ אקסקיושן אז אם יש לנו שגיאת תחביר אז כמובן שהמנגנון הזה מצליח להבין שטעינו ומיד לסמן לנו את המקום המדויק פגיעה נוספת אנחנו יכולים לנסות להדפיס
משתנה נ"מ ובכלל לא הגדרנו משתנה כזה אנחנו חייבים להגדיר את המשתנים אז זה גם כן איזשהו סוג של תחביר היינו צריכים להגדיר אותו או להכיר אותו. אז הקומפיילר נותן לנו את השגיאות האלה, שגיאות קומפילציה זה השגיאות הכי פשוטות לטיפול, מפני שא', יש לנו סימון מדויק של הבעיה, ב', יש לנו הסבר מה בדיוק קרה, וג', אם אנחנו לא מצליחים לתקן את השגיאה
אנחנו לא יכולים להריץ את התוכנית, אז אין שום סכנה בזה, אנחנו צריכים לתקן ואז להריץ. הערה בנוגע לשגיאות קומפילציה, שהם יודעים איך לתכנת לא משאירים אף פעם שגיאות קומפילציה.
ברגע שיש לכם שגיאת קומפילציה הכי קטנה שיכולה להיות חייבים מיד ללכת ולטפל בה. סיבה ראשונה אם אנחנו לא נטפל בה אנחנו נצבור כל מיני שגיאות קומפילציה נוספות ובסוף אנחנו נגיע למצב שיכול להיות שיש לנו המון המון שגיאות ולא יהיה לנו יותר מדי קשה לאתר בדיוק ולתקן אותן.
וסיבה שנייה יכול להיות לא תמיד אבל יכול להיות שאם קיימת שגיאת קומפילציה אז האינטליסנס שכרגע אתם רואים אותו לפעמים הוא לא עובד. לפעמים הוא לא עובד טוב, כרגע הוא כן עובד, אבל לפעמים פשוט אין אינטליסנס, ופתרון לזה זה פשוט תיקון שגיאות הקומפילציה והמשך פיתוח התוכנית.
הסוג השני זה שגיאות שנובעות בריצת התוכנית ובעצם גורמות לתוכנית לקרוס. בואו ניקח דוגמא. נניח שיש לנו פה איזשהו משתנה num, ואנחנו לפני זה באים ואומרים למשתמש enter number.
לעת אנחנו רוצים לגשת ולקלוט איזשהו מספר וכמובן להפוך אותו על ידי convert למספר ובואו נניח שנציג איזושהי הודעה שהמספר כפול עצמו שווה לאיזשהו ערך יש לנו פה num, באמת שאפשר לעשות דבר כזה, num כפול num דבר ראשון בואו נריץ ונראה שהכל עובד כמו שצריך אם אנחנו מכניסים 12 אז
אנחנו רואים ש-12 כפול 12 שווה 144 בסדר, אבל מה קורה אם המשתמש מריץ ומכניס 12 ובטעות לחץ על A או לא בטעות או לא הבין מה הוא רוצה להכניס?
ואנחנו רואים את הדבר הזה. והדבר הזה זה שגיאה שהתרחשה במהלך הריצה שגרמה לתוכנית לקרוס. כרגע התוכנית בעצם קרסה ואם אנחנו נפסיק את החלון הזה, זה לא משנה אם אנחנו נלחץ yes או no, אז התוכנית בעצם תפסיק.
וזאת שגיאת ריצה, או במילים אחרות חריגה, באנגלית exception. אז הטיפול בשגיאות כאלו הוא מנגנון מיוחד שאנחנו הולכים לראות בסרטון הזה שנקרא מנגנון טיפול בחריגות, מנגנון exception handling.
הסוג השלישי של השגיאות שקיימות זה שגיאות לוגיות. שגיאה לוגית זה שגיאה שלא גורמת לתוכנית לקרוס, אבל ישנה איזושהי שגיאה שם.
אפילו בואו ניקח את המקרה הזה. כאן אנחנו רואים שביצענו איזשהו חישוב מתמטי אבל בואו נניח שיש לנו מעין דבר כזה. בטעות שמנו פה פלוס אחד. אנחנו מריצים ואנחנו מכניסים 12 ואנחנו רואים ש-12 כפול 12 שווה 145 ויכול להיות שמישהו ישים לב לזה ויכול להיות שאף אחד לא ישים לב לזה והשגיאה הזאת פשוט תמשיך לחיות לה.
היא לא גרמה לתוכנית לקרוס והסוג שגיאה הזאת זה הסוג שגיאה הכי חמור שיכול להיות ונקרא שגיאה לוגית כלומר שגיאה באלגוריתם שלא נתגלתה ומעכשיו והלאה יש פה איזושהי טעות בתוכנית איזשהו באג ומאוד קשה לעלות עליו.
והבאגים האלה יכולים להיות כאלה שהם נסתרים ותוכניות יכולות להכיל אותם אף אחד לא רואה אותם פשוט תוכניות שנותנות תוצאות שגויות. אז בגלל שהבאג הזה לא גרם לתוכנית לקרוס אז לא מטפלים בו על ידי שגיאות של exception handling טיפול בחריגות כי אין פה חריגה השיטה הכי טובה למנוע שגיאות כאלה זה פשוט לא לעשות אותן או שאפשר פשוט לרוץ עם דיבאגר שלב שלב ולחפש
אותן או לקחת מישהו שבודק את התוכנית בארגונים יש יחידה שנקראת יחידת qa quality assurance שהתפקיד שלהם זה גם לחפש שגיאות כאלה ולהתקיל את התוכניות שהמתכנתים עשו ואז רק אפשר למצוא ולתקן אותן אז אנחנו הולכים בסרטון הזה לטפל
שגורמות לקריסת התוכנית. בואו ניפטר ממה שעשינו פה וכעת נלך ונצרף איזשהי קלאס והמחלקה שאנחנו הולכים לצרף נקראת array services ואנחנו רוצים לבנות איזושהי פונקציה, זו לא פונקציה סטטית שנקראת get average היא מקבלת איזשהו מערך, רצה עליו, סוכמת את כל האיברים שלו ומחזירה
תחום האיברים לחלק לאורך של המערך וזה נותן לנו את ממוצע איברי המערך. כעת אנחנו רוצים לגשת ולהשתמש עם הפונקציה. זה אומר שאנחנו צריכים לבנות איזשהו מערך.
בואו נבנה פה פרייט, נציג את הממוצע שלו, נריץ ונראה שהממוצע זה 44. עכשיו אנחנו זוכרים שמי שכותב את המחלקה זה לא מי שמשתמש בה, ויכול להיות שמישהו עכשיו ישתמש במחלקה הזאת וישלח את המערך הבא.
מה בעצם הוא שלח? הוא שלח מערך ריק, אז מה האורך שלו? האורך שלו זה 0. האם מותר לחלק ב-0? לפי חוקי המתמטיקה אסור כי התוצאה היא אינסוף ואם אנחנו מריצים את זה אנחנו מקבלים משהו מאוד מוזר על המסך ולמעשה מה שקיבלנו זה ערך דאבל שמחזיק אינסוף פשוט האינסוף נכתב פה בעברית בגלל מערכת ההפעלה
הקונסול לא מצליח להציג עברית אז אנחנו רואים את הג'יבריש הזה אבל אנחנו רואים שיש פה איזושהי בעיה שקרתה והיא עדיין לא גרמה לקריסת התוכנית אבל מה אנחנו עושים בשביל לטפל בה?
אז קודם כל אנחנו הולכים לראות את כל הסיפור של הטיפול בחריגות מהצד השני. זאת אומרת, מקודם אנחנו ראינו דוגמה לקריסה, בואו נחזיר רגע את הדוגמה שראינו.
בדוגמה הזאת ביקשנו מהיוזר להכניס מספר, היוזר הכניס מספר שהוא שגוי או לא מספר בכלל, הוא הכניס איזושהי מכרוזת וההכנסה של המכרוזת גרמה לקריסת התוכנית.
אז אם נחקור מה קרה כאן בעצם אז נראה שconsole readline החזירה מחרוזת ולא מספר convert to int 32 לא הצליחה להמיר את המחרוזת למספר אמיתי ולכן היא גרמה לקריסה מי שגרם לקריסה זאת הפונקציה to int 32 אם אנחנו נריץ את זה ונכניס abc אנחנו נראה שיש פה קריסה עכשיו למה אני מתכוון כשאני אומר שאנחנו הולכים ללמוד את
כל הדבר הזה מהכיוון השני בנושא טיפול בחריגות היה אמור להיות טיפול בקריסה שקרתה. אבל לפני זה, למה בעצם קרתה קריסה? אז קודם כל אנחנו רוצים להבין למה הייתה קריסה ומי יזם את הקריסה.
אז ראינו שמי שיזם את הקריסה זאת הפונקציה toInt32. הסיבה שהיא יזמה את הקריסה היא כי היא מצפה לקבל מכרוזת שמתארת מספר והיא קיבלה מכרוזת שלא מתארת מספר.
במילים אחרות אפשר להגיד שהפונקציה 2in32 ציפתה לקבל איזשהו ערך מסוים לסוגריים שלה וקיבלה ערך שגוי. אם היא קיבלה ערך שגוי היא לא יכולה לעבוד איתו ואין לה מה לעשות איתו ולכן היא יזמה קריסה ואז התפקיד של מי שמשתמש עם הפונקציה זה לטפל בקריסה במידה והיא קרתה יכול להיות
שאנחנו הולכים להפעיל את הפונקציה טור אין 32 בצורה כזאת. בצורה כזאת היא בחיים לא תקרוס כי אין פה קלט מהמשתמש או מקובץ אלא תמיד יש פה נתון חוקי שאנחנו שולחים לפונקציה.
אבל זה לא המצב פה ולכן אנחנו נאלצים לטפל בבעיה אבל לפני שאנחנו הולכים לטפל בבעיה בכדי למנוע מהתוכנית לקרוס אנחנו מבינים שפונקציות שמצפות לקבל פרמטרים לסוגריים ומצפות שהפרמטרים שיגיעו לסוגריים צריכים להיות בעלי אופי מסוים או ערכים מסוימים או איזושהי חוקיות מסוימת אם הן לא מקבלות בדיוק את מה שהן מצפות לקבל הן לא יכולות לעבוד הן לא יכולות להחזיר ערך
ולכן הן עושות משהו שנקרא גרימה לקריסה יזומה במונח מקצועי זה נקרא העלאת חריגה ולמעשה כל החריגות בתוכנית או רוב החריגות בתוכנית נגרמות בגלל פונקציות כאלה וזה ממש בסדר בפיתוח תוכנה שפונקציה שמקבלת נתון שגוי מבחוץ לא תסכים להמשיך לעבוד ותגרום לחריגה ואז מי שמשתמש בפונקציה יצטרך לטפל בה.
ככה ונכון לעבוד בפיתוח תוכנה Object Oriented. עכשיו אם אנחנו חוזרים בחזרה לדוגמה שראינו יש לנו פה משהו שהוא לא כל כך אופטימלי.
יש לנו את הפונקציה getAverage שאנחנו כתבנו והיא בכלל לא בודקת אם הערך שהיא קיבלה הוא חוקי או לא חוקי ולכן היא הרשתה להחזיר איזשהו ערך שהוא לא בסדר.
אם אנחנו נריץ את זה אנחנו נראה שחזרנו הג'יבריש הזה כרגע שבסך הכל זאת המחרוזת אין סוף בעברית. טוב, אז מה אנחנו עושים?
אז מה שאנחנו עושים, אם אנחנו כותבים פונקציה שמקבלת ערך מבחוץ והערך הזה חייב להיות מבחינתנו חוקי, הדבר הראשון שעלינו לעשות בתוך הפונקציה זה לבדוק אם הערך הוא חוקי מבחינתנו ואם הוא לא חוקי, לגרום לגריסה יזומה.
אלא אם כן, אנחנו כן יכולים להחזיר משהו שמציין את הבעיה או שמציין מבחינתנו משהו בסדר. ברוב המקרים זה לא המצב, ברוב המקרים אם פונקציה מקבלת נתונים לסוגריים והביאו לה נתון שגוי, היא חייבת מיד לבדוק ולהחזיר או לגרום לקריסת התוכנית.
ואנחנו עכשיו צריכים לבדוק האם המערך שקיבלנו הוא ריק. ומערך ריק זה אומר שאו המערך זה נ"ל, מבחינתי זה לא בסדר, אי אפשר להביא לי מערך או כתובת של מערך שלא מצביעה באמת על מערך אמיתי ולצפות לקבל ממוצע, שכן הביאו מערך כמו במקרה הזה שלנו אבל הלנקס שלו הוא 0. בשני המקרים האלה אני לא מוכן
להמשיך הלאה ואני רוצה לגרום לקריסה יזומה. עכשיו פה אתם יכולים לשאול את עצמכם מה פתאום לגרום לקריסה יזומה הרי זה לא יהרוס את התוכנית ויגרום לגריסת התוכנית והלקוח יתעצבן ולא יצטרך להריץ את התוכנית אז אתם צודקים אבל האחריות של מי שמשתמש במחלקה ובפונקציה לחזות את המצב הזה שיש לנו פה אקספצ'ן ולטפל
בבעיה על ידי טיפול בחריגות שאנחנו עוד מעט הולכים לראות איך הוא יעשה את זה. איך אנחנו גורמים לקריסה יזומה? והמילה הראשונה שאנחנו הולכים ללמוד במנגנון הזה נקראת throw.
בעברית זרוק. throw באה ואומרת אני זורקת חריגה, אני מפה גורמת לקריסת התוכנית. כל אובייקט חריגה שנזרק או כל חריגה שנזרקת מיוצגת על ידי איזשהו אובייקט שמתאר מה הבעיה שקרתה כל האובייקטים הם מטיפוס של אקספשן או נגזרות של אקספשן זאת אומרת אם אנחנו זורקים חריגה אנחנו חייבים להיות או טיפוס אקספשן
שאנחנו זורקים אותו על ידי המילה throw או נגזרות של אקספשן עכשיו למה אין פשוט מחלקה אחת ויחידה נניח אקספשן שמתארת את החריגות כי כאשר אנחנו זורקים חריגה אנחנו רוצים לתאר את הבעיה בצורה הכי נכונה שיכולה להיות.
אז אם אנחנו עכשיו זורקים exception אנחנו יכולים בקונסטרקטור של האובייקט לתאר מה הבעיה. נניח הרי can't be empty. במידה ופונקציה יש בה את המילה throw והתוכנית מגיעה למילה throw היא לא תמשיך הלאה ומיד תגרום לקריסה.
עכשיו הקוד שמשתמש במחלקה ייאלץ לטפל בבעיה. טוב בואו נריץ ונראה עכשיו שהתוכנית קרסה והקוד שמשתמש בה צריך לטפל בבעיה. במידה ושולחים לי מערך שהוא בסדר, כמובן אין לי שום קריסה בתוכנית.
אז איך אנחנו מטפלים בבעיה? טיפול בבעיה מכיל מספר מילים שמורות. המילה הראשונה זה try. try זאת מילה שמכילה בלוק שעוטף את כל הקוד שמנסה לקרוא לפונקציה שלנו ולפונקציות אחרות.
באנגלית הוא אומר בוא תנסה, אני לא יודע אם אתה תצליח או לא, בוא תנסה את זה. לאחר מכן אנחנו צריכים לרשום catch ואז את הסוג של החריגה שהולכים לזרוק לנו. ופה אנחנו פותחים איזשהו משתנה בשביל לתפוס את החריגה.
המשתנה הזה זה האובייקט שנזרק. שימו לב שכאן אנחנו יצרנו אובייקט חדש עם המילה new ופה אנחנו תופסים אותו. אז אחד מהדברים שיש לו זה message. מסג' זאת בעצם החרוזת שמתארת מה הבעיה עם השגיאה שקרתה כרגע.
בואו נריץ, ונראה שעכשיו התוכנית לא קורסת אלא מוצגת הודעה חוקית על המסך, הרי can't be empty.
בעצם האזור קוד של הפונקציה בדק את הפרמטר שהוא קיבל מבחוץ, במידה והוא לא היה בסדר הוא זרק חריגה, האזור קוד שמשתמש איתו טף אותו בבלוק טריי, בלוק קאץ' טיפל בחריגה.
במידה ואין שום חריגה בלוק ה-try מצליח להסתיים בהצלחה. בואו נרשום פה end of try. אז אנחנו אמורים לראות את ה-end of try כי לא הולכת להיות פה שום חריגה ובנוסף בלוק ה-catch בכלל לא הולך להתבצע.
בואו נריץ ונראה שיש לנו הצגה של הממוצע ו-end of try. במידה והייתה חריגה, בואו נחזיר את זה, מיידית תתבצע קפיצה לבלוק קאץ' המתאים שיש.
כאן אנחנו רואים שיש throw, המערכת תצא מהפונקציה, תחזור לפקודה הזאת ומיד תקפוץ מעל כל הקוד שיש אחריה עד שהיא תיכנס לבלוק קאץ' מתאים ותבצע את הבלוק קאץ'.
בואו נריץ ונראה שלא מוצג לנו ה-end of try כי המערכת דילגה עליו. זה אומר שמה שאנחנו עושים בתוך בלוקי הcatch שאנחנו כותבים זה אך ורק טיפול בבעיה שקרתה מפני שאם לא הייתה שום בעיה אנחנו לא נגיע לשום בלוק catch ואם הגענו לבלוק catch בוודאות הייתה איזושהי קריסה ולכן אנחנו צריכים לטפל בה וזה המטרה של בלוקי הcatch
טיפול בבעיה. עכשיו מקודם אמרתי שכאשר אנחנו זורקים חריגה כלומר אנחנו פה בתוך הפונקציה שאנחנו בונים משתמשים במילה throw בשביל לעצור את התוכנית, לברוק חריגה כך שמישהו יטפל בה כי קיבלנו כמובן ערך שגוי מבחוץ אז אנחנו חייבים לזרוק את החריגה הכי מדויקת שיכולה להיות.
פה אנחנו הולכים לראות למה בעצם עלינו לזרוק את החריגה הכי מדויקת שיכולה להיות. אז קודם כל אנחנו רואים שיש לנו כאן throw new exception וראינו ש-exception זה המחלקה הכי גבוהה של כל מחלקות החריגה זאת מחלקת ה-bethith של כל החריגות אז היא בעצם לא מתארת באמת חריגה ספציפית אלא מתארת חריגה מאוד מאוד כללית שיכולה להיות.
אז למה אנחנו צריכים לברוק חריגות ספציפיות? והסיבה היא בכדי לתת אפשרות למי שמשתמש בפונקציה שלנו לכתוב מספר קאצ'ים בכדי לטפל באופן שונה בסוגים שונים של חריגות.
זאת אומרת מי שכותב את המחלקה יכול עכשיו או יותר נכון מי שמשתמש במחלקה הוא יכול עכשיו לכתוב מספר קאצ'ים. בואו נראה איך זה מתבצע. אנחנו כאן יכולים לבדוק דבר ראשון האם הרי הוא נאל.
אם מישהו שלח לי נאל אני רוצה לזרוק טיפוס שנקרא נאל, או יותר נכון ארגיומנט נאל אקספצ'ן. ארגיומנט זה מילה שמתארת משתנה שנשלח לפונקציה.
ארגיומנט נאל אקספצ'ן זה טיפוס שהוא אקספצ'ן שהוא יותר ספציפי ואומר יש לי איזשהו ארגומנט בפונקציה הפרמטר name שלו נקרא arr ומישהו שלח לי null ואז במידה ולא אנחנו נמשיך בתוכנית ואנחנו בודקים האם הוא בעל length 0 אם כן יש לנו את argument exception argument exception מתאר בעיה כללית עם פרמטר
כאן אנחנו יכולים לשלוח הרי can't be null can't be empty בסדר אז עכשיו יש לנו פה שתי זריקות שונות אם שלחו לי פרמטר שהוא נל הוא לא מצביע בכלל על מערך אז הזריקה שאני זורק כרגע throw new argument null exception והיא מציינת שוואלה הביאו לי נל ואסור להביא לי נל במידה והביאו לי מערך ריק שזה לא נל זה מערך פשוט באורך 0 ואני זורק argument exception קצת יותר מדויק בכל מקרה אני לא זורק פה כרגע
exception למרות שיכלתי אבל אני לא זורק בואו נריץ כרגע את התוכנית ונראה שזה לא קורס למרות שזרקנו כרגע ארגומנט אקספצ'ן והצלחנו לתפוס את זה באקספצ'ן.
בואו נשלח נאל. במקום הרי פשוט נשלח נאל. אנחנו רואים שיש לנו value can't be null, פרמטר name הרי, שוב פעם.
התוכנית לא קרסה למרות שהפעם היה ארגומנט נאל אקספצ'ן. איך זה יכול להיות? הרי אנחנו לא תפסנו את הטיפוסים האלה, והתשובה לשאלה צריכה לבוא מתחום הפולימורפיזם באובג'קט אוריינטד.
ומה שקורה כאן זה שאנחנו זורקים איזשהו אובייקט והאובייקט הזה יכול להיתפס ברפרנס בסיס שלו. זה בדיוק כמו שאתם שולחים לפונקציה שמקבלת פרסון אובייקט מסוג אמפלואי שיורשת פרסון, או אובייקט מסוג מנאג'ר שיורשת אמפלואי ואמפלואי יורשת פרסון.
ואין שום בעיה לשלוח אובייקט מנאג'ר לפונקציה שמקבלת פרסון. אין שום בעיה לשלוח אובייקט לדוגמה אמפלואי לפונקציה שמקבלת אובג'קט.
מפני שאם יש לנו את הבסיס הוא יכול לתפוס גם אובייקטים שהם נגזרות. אז זאת הסיבה שיותר קל לנו להבין כרגע למה אנחנו יכולים לזרוק כל מיני סוגי חריגות ולתפוס את כולם עם אקספצ'ן.
כי היא הבסיס של כל האקספצ'נים שיש. בואו נריץ את כל התוכנית הזאת עם דיבאגר. יותר קל להבין מה קרה פה אני בעצם מריץ את התוכנית אני עוצר בנקודת העצירה ונכנס לתוך הפונקציה עם f11 נכנס לתוך הפונקציה ממשיך בתוכנית ואני רואה שקיבלתי איזשהו מערך והגודל שלו זה 0 אז הוא כמובן לא שווה ל-null אז אנחנו ממשיכים הלאה ואנחנו בודקים האם ערכו שווה
0 בואו נשים את העכבר על הלנקס נראה שהוא 0 ניכנס לתוך ה-if ונגיע ל-throw ברגע שהגענו ל-throw התוכנית בעצם קופצת מיידית ואנחנו רואים שדילגנו על כל הקוד הזה ועל כל ה-Consol right line ועל כל מיני דברים אחרים דילגנו על הכל לא המשכנו בכלל את הפונקציה מיד התוכנית יצאה והתחיל לחפש catch שמסוגל לטפל בבעיה והcatch הזה אכן מסוגל לטפל בבעיה אם אנחנו
מסתכלים בואו נמשיך טיפה קדימה מה יש בתוך ה-ex אנחנו יכולים לראות שיש שם אובייקט אקספצ'ן, אנחנו יכולים לראות את המסאג' הרי קאנט בינאל, קאנט בי אמפתי סליחה, את הסורס, איזה פרויקט זה, סטאק טרייס, מראה לנו את הפונקציות שהביאו עד לנקודה הזאת, שגרמו לבעיה.
אוקיי, אז יש לנו כאן בעצם כל מיני נתונים, ואנחנו פשוט הצגנו רק את המסאג', ולכן אנחנו רואים פה את המסאג' של המסך, הרי קאנט בי אמפתי. אוקיי, אז בואו נעצור את זה, וכעת מה זה עזר לנו?
שאנחנו שלחנו פה כל מיני טיפוסים שונים של חריגות ופה אנחנו טיפלנו בכולם באותו האופן. אז למעשה כשבנינו את המחלקה בנינו אותה כמו שצריך.
זרקנו סוגים שונים של בעיות כתלות בבעיות שיכולות לנבוע מהפרמטר שהתקבל. אבל מי שטיפל בבעיה פשוט החליט לטפל בכל האקספשנים שיכולים להיזרק בתוכנית הזאת באותו האופן והוא יכל גם להחליט לבצע קאצ'ים אחרים.
איך עושים את זה? אומרים כזה דבר: במידה ומישהו זורק לי argument null exception אני רוצה להציג איזושהי הודעה ספציפית שאומרת you can't send null.
במידה ומישהו שולח לי argument exception אז אני רוצה להציג בוא נניח את הודעת שגיאה שהגיעה מהמסג'. במידה ויש לי חריגה כללית, אז אני רוצה להציג, בואו נניח ג'נרל אירו.
שימו לב שבקאצ' הראשון לא השתמשתי עם האובייקט שנזרק במיטה, ואני לא משתמש עם האובייקט שנזרק, אני לא חייב לרשום אותו בקאצ', אני יכול לרשום דבר כזה.
בואו נריץ כרגע ונראה שהוא מציג לנו את ה-array can't be empty, אבל בואו נסתכל על זה עם דיבאגר. אני מריץ, אני נכנס לתוך הפונקציה, אני רואה שהוא הולך לזרוק בגלל שיש לי מערך ריק, וה-catch המתאים שהולך להיתפס זה argument exception בגלל שנזרק argument exception.
ואז טיפלנו ספציפית בבעיה של argument, כלומר ערך שנשלח לפונקציה שהוא לא חוקי. הצגנו את הבעיה על המסך. אוקיי, בואו ניקח דוגמה שבה אנחנו שולחים null.
נריץ את התוכנית עם F5, נעצור בבריק פוינט, ניכנס לפונקציה, נראה כעת שיש לנו האם הרי שווה נל תשובה כן אנחנו הולכים לזרוק ארגיומנט נל אקספצ'ן ולתפוס אותו עם הקאצ' של הארגיומנט נל אקספצ'ן בדיוק מה שקרה עכשיו אנחנו מציגים you can't send null בואו נסתכל במה שיש לנו
זאת אומרת שמי שמטפל בבעיה יכול להבין שיש כל מיני בעיות שיכולות לנבוע מהפונקציה שאנחנו מטפלים בה ולכתוב לעצמו כל מיני קאצ'ים עכשיו, מאיפה זה שמטפל בבעיה יודע שהמחלקה או הפונקציה הזאת זורקת ספציפית ארגימנט מעלה?
אקספצ'ן או ארגימנט אקספצ'ן? אז למעשה אין לו שום יכולת לדעת את זה, אלא אם הוא קורא תיעוד על הפונקציה. ותיעוד על הפונקציה אנחנו רושמים בעברת תיעוד xml, זה נקרא תיעוד xml בצורה כזאת, כמו שלמדנו בקורס המבוא לתכנות ואלגוריתמיקה, וכאן בעצם הוא הולך ומתאר בדיוק את הפונקציה
ואומר Getting average from an int array Parameter name array, the array, to