Error Handling - טיפול בשגיאות
Page מגדירים debug="true", ואז השגיאה מוצגת עם השורה האדומה בקוד. בהרצה עם F5 (ולא Ctrl+F5) הדפדפן עובר למצב דיבאג ישירות על השורה שגרמה לקריסה. את ההגדרה ברמת כל האתר עושים ב-web.config, בתגית compilation עם debug="true". בשרת שעולה לאוויר חשוב להחזיר ל-false, כדי שלקוחות לא יראו את הקוד או את פרטי השגיאה.int.Parse על טקסט לא מספרי זורק FormatException, ומספר גדול מדי זורק OverflowException. לכן ב-try-catch עושים בלוק catch נפרד לכל סוג, ובסוף בלוק כללי שתופס את Exception. בתוך הבלוקים מציגים הודעה ללקוח בתווית שצבעה אדום.Page_Error מתרחש לפני הקריסה. בתוכו קוראים ל-Server.GetLastError() כדי לקבל את האובייקט של השגיאה, בודקים את הטיפוס עם is, וקוראים ל-Server.ClearError() כדי לומר שטופלה. בגלל שהדף מתרוקן בזמן טיפול כזה, את ההודעה כותבים עם Response.Write, ומוסיפים קישור חזרה לדף. הקישור בונה את הנתיב המלא של הדף הנוכחי ב-Request.Url.Application_Error, שתופס כל שגיאה שלא טופלה במקום אחר באתר. השגיאה שנתפסת היא בדרך כלל עטופה באובייקט פנימי, ולכן לוקחים את InnerException אחרי בדיקה שהוא אינו null.customErrors עם mode, מגדירים מה קורה בשגיאה שלא טופלה. ניתן להגדיר דף ברירת מחדל, וגם הפניה לדף נפרד לפי קוד שגיאה: 404 לדף שלא נמצא, ו-403 לגישה שנדחתה. בשיעור מוצגים דפי HTML שונים לכל קוד.פרקי ההרצאה: Error Handling - טיפול בשגיאות
תמלול ההרצאה: Error Handling - טיפול בשגיאות
הטקסט המלא של הדקות הראשונות בהרצאה «Error Handling - טיפול בשגיאות» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
בשיעור היום אנחנו הולכים ללמוד על טיפול בשגיאות, Error Handling. כאשר לקוח משתמש באתר שלנו, הוא יכול לייצר בטעות הרבה שגיאות, ואנחנו צריכים לדעת איך לטפל בהן.
אז בואו נייצר שגיאה, ונראה איך אפשר לטפל בה. נגדיר למשתמש אפשרות להכניס מספר. נקלוט אותו, ונציג את החזקה שלו. המשתמש מכניס מספר בתיבת הטקסט.
בלחיצה על הלחצן אני רוצה להציג את החזקה הריבועית של המספר. אז בואו נכתוב את הלחצן בהנחה שאני מניח שהכל בסדר והמשתמש לא טועה לעולם באינפוט שהוא מכניס.
מה הייתי עושה? הייתי לוקח איזשהו אינטג'ר num. הייתי מכניס לתוכו את מה שנכנס בתיבת טקסט לאחר המראה. הייתי לוקח עוד משתנה עבור החזקה זה אמור להיות num כפול num ולבסוף מציג את זה בלייבל.
בואו נבדוק כרגע את האתר נגדיר את ההומפייג' כset as start page ונריץ. מכניס מספר, ציג show power ונראה ש-12 בריבוע זה 144, הכל טוב ויפה.
אבל איזה שגיאות יכולות לעלות מהקוד הזה? ראשית, מה קורה אם המשתמש לא מכניס מספר אלא מכניס ABC? בואו נבדוק ונראה שמה שקרה כרגע זאת קריסה של האתר.
בצד השרת התרחשה קריסה, מה זה אומר? זה אומר שהקוד בשרת קרס כרגע דפדפן רק אומר לי שהתבצעה קריסה בשרת. כמובן שבמציאות אסור לנו להגיע למצב כזה. אסור לנו להגיע שפעילות של הלקוח גרמה לאיזושהי קריסה בצד של השרת.
אם אני קורא מה קרה כאן, אני רואה שהשרת אומר לי server arrow in arrow handling, זה השם של האתר שלי, application input string was not in a correct format, איזושהי הודעת שגיאה שקרתה.
הוא ממשיך לתאר כאן מה קרה, אבל יותר מזה הוא לא אומר לי. קודם כל, אם אני רוצה באמת לגלות בצורה קצת יותר מפורטת בזמן הפיתוח, לא בזמן ההרצה של האתר באוויר, אלא בזמן הפיתוח, מה בדיוק גרם לשגיאה, או יותר נכון באיזה שורה השגיאה קרתה, אני רואה שהדף הזה אומר
לי מה אני צריך לעשות בשביל לתת לי מידע קצת יותר מפורט. בהנחה שאני בתור מתכנת לא יודע מה הייתה הבעיה. ראשית, הוא אומר לי, לך לתגית page ותגדיר debug=true.
בואו נסתכל מה יקרה אם אני אגדיר את זה בתגית page. נחזור לדף שלנו, נלך לסורס, תגית page, ונגדיר דיבאג שווה true.
בואו נריץ שוב פעם, שוב נכניס מחרוזת שגויה. עכשיו אנחנו רואים עדיין שקרתה קריסה כמובן, אבל מה שאני רואה זה מידע נוסף בקשר לשגיאה. למעשה מה שאני רואה זה את הקוד שלי שכתבתי בצד השרת ב-c-sharp, עם שורה אדומה בדיוק על המיקום שקרס.
עכשיו אם אני מעלה את האתר הזה לאוויר ולקוח רואה את זה זה כמובן אאוט סקיוריטי ואסור שלקוחות בכלל יראו את הקוד שיש לי בצד של השרת שלא לדבר על זה שאסור שהם בכלל יראו שקרתה קריסה אנחנו עוד מעט הולכים לטפל בזה אבל הדבר הזה שהוא מראה לי בדיוק היכן הייתה הקריסה זה טוב לי מבחינת הפיתוח בשביל למקד אותי בדיוק בבעיה שקרתה ואכן
אני רואה שהמידע שקיים בתיבת הטקסט לא יכול להיות מומר לאינטג'ר בצורה ישירה במידה והמידע הזה לא מכיל מספר טהור אז א' אני רואה שקרתה כאן שגיאה אני יודע בדיוק באיזה שורה היא קרתה ואני יכול עכשיו לגשת ולטפל בה בשביל לראות את האתר הזה בצורה כזאת את האינפוט את האוטפוט הזה בצורה כזאת הרצתי את האתר שלי עם ctrl f5 ctrl f5 מדמה הרצה על ידי הלקוח אם הייתי מריץ
את האתר הזה על ידי f5 זה אומר לחיצה על הפליי שמופיע כאן הייתי רואה משהו קצת אחר. ראשית, יש לי פה איזושהי הודעה, אנחנו תכף נראה מה ההודעה הזאת, אני עושה אוקיי, אתר רץ, אני מכניס ABC,
מנסה ליצור שגיאה, אבל הפעם בגלל שהרצתי את זה עם F5, אנחנו הולכים לראות שהאתר קורס ונכנס אוטומטית למצב דיבאג, אנחנו רואים את זה כאן, ומצביע לי בדיוק על השורה שגרמה לקריסה.
וההודעה שמקודם הוצגה לי בדפדפן מוצגת לי כאן בתיבה הזאת. וזה עוד שיטה בזמן הפיתוח בכדי לגלות בדיוק היכן התבצעה הקריסה.
אוקיי, בואו נעצור ונסתכל על דבר נוסף. דיבאג שווה true אפשר לי לבדוק את השגיאה הזאת רק בדף הנוכחי. אם אני רוצה לבדוק את השגיאה, או יותר נכון לקבל פירוט נרחב לגבי השגיאה בכל דפי האתר בבת אחת בזמן הפיתוח, אני צריך ללכת ל-WebConfig ולהגדיר כאן דיבאג שווה true בתגית Compilation, שנמצאת בתגית system.web שנמצאת בתגית
configuration ברגע שעשיתי את הדבר הזה ואומר שכל האתר שלי בכל הדפי האתר במידה ותתבצע בהם קריסה אנחנו נקבל את המידע המפורט הזה אבל יש לשים לב אם אני מעלה את האתר הזה לאוויר חשוב מאוד להפוך את הדבר הזה ל-false בכדי שלקוח במידה והוא יקבל איזושהי קריסה לא יראה את המידע שקיים בצד השרת ולא יראה בדיוק איפה הייתה הקריסה בצד השרת
כי זה OutSecurity אז הוא יראה את הקוד שכתבתי בשרת ויכול להיות שהוא ישיג מהקוד הזה אם הוא יראה אותו מידע שישמש אותו בשביל להפיל לי את האתר בעתיד.
אוקיי, אז אם אני שם את זה כדיבאג שווה false ושוב פעם מריץ את האתר ב-F5 אני רואה את ההודעה הזאת וכל מה שההודעה הזאת אומרת זה שאם אני לוחץ אוקיי היא תשנה לי את הדיבאג הזה לטרו בכדי שאני אוכל לראות מידע מפורט בקשר לשגיאה.
ובגדול מה שההודעה הזאתי ציינה לי. בואו נסתכל רגע, נסגור את האתר, נחזור ל-WebConfig ונראה דיבאג שווה טרו זה מה שההודעה עשתה. אם כרגע אני אריץ את זה עם F5 בגלל שדיבאג שווה טרו האתר יכול להמשיך לרוץ בצורה רגילה וכמובן אם תתבצע קריסה והרצתי את זה עם F5 אני אקבל את השורה המדויקת במצב דיבאגר אם אני אריץ את האתר הזה עם קונטרול F5 ותתבצע