
try catch בכל route.trusted connection ל-false בלי להגדיר שם משתמש וסיסמה. בקשה לכל הספרים מחזירה 500 (internal server error) עם הודעה שאנחנו לא רוצים שהלקוח יראה.internal server error, שמקבלת message ומעבירה אותו ל-base.try catch ב-route: עוטפים את הקוד, ובחריגה מחזירים JsonResult עם אובייקט השגיאה (ההודעה של החריגה) ו-StatusCode מתוך status codes, שהוא 500 (internal server error). הלקוח מקבל את האובייקט שלנו והשרת לא קורס.try catch בכל route: כותבים פילטר ברמת האפליקציה, CatchAllFilter שמממש את IExceptionFilter. הפונקציה OnException מקבלת context, ובה אותו קוד: context.Exception.Message, יצירת JsonResult, הצבתו ב-context.Result, ו-context.ExceptionHandled = true כדי לומר ל-dotnet שהחריגה טופלה כאילו נתפסה ב-catch. חריגה שטופלה לא מגיעה אליו, ורק חריגות שלא טופלו מתנקזות לשם.AddMvc דרך options.Filters.Add<CatchAllFilter> כך שיחול על כל ה-controllers. אחר כך אפשר למחוק את ה-try catch.inner exception. לכן כותבים פונקציה רקורסיבית GetInnerMessage: אם החריגה null מחזירה מחרוזת ריקה, אם אין InnerException מחזירה את ההודעה, ואחרת קוראת לעצמה עם ה-inner. תוצאה: "No process is on the other end of the pipe", הודעה פנימית יותר שאפשר לחפש בגוגל.הטקסט המלא של הדקות הראשונות בהרצאה «טיפול בקריסות בצד השרת» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
סוג השגיאה הבאה שאנחנו רוצים לטפל בה זה קריסה בשרת. זה כבר לא שגיאת ארבע מאות, כלומר ארבע ומשהו, ארבע מאות, ארבע מאות ואחת, שתיים, שלוש, ארבע וכולי, אלא שגיאת חמש מאות.
חמש מאות זה אומר באמת הייתה פ-- היה פדיחה בשרת והוא קרס. בואו נייצר פדיחה כזאת. נניח שכרגע, אם אנחנו מסתכלים על ה-connection string אנחנו רואים ש...
אנחנו לא צריכים להגדיר איזשהו, אה, שם משתמש וסיסמה עבור הדאטה בייס הזה, כי trusted connection שווה true. והפרויקט רץ והכול בסדר וכולם עובדים. יום בהיר אחד מישהו שנמצא בשרת ויש לו גישה לקובץ הזה בא ואומר "וואלה, אני כן רוצה להגדיר username ו-password", משנה לי את זה ל-false אבל לא מגדיר שם משתמש וסיסמה.
אז מן הסתם המערכת תקרוס ברגע שאני מנסים לבצע איזו פעולה מסוימת וזה באמת פדיחה של השרת. מישהו הרס משהו בשרת. אז מה אנחנו עושים?
אז בואו נריץ רגע Ctrl F5 ונלך ל-Postman וננסה פשוט להביא את כל הספרים. ואנחנו רואים שיש לנו, אה, קריסה חמש מאות. אז קודם כל זה מעולה שקיבלנו בחזרה חמש מאות, זה internal server error.
עד כאן הכול טוב, אבל מה זה? מה זה ההודעה הזאת? אמרנו אנחנו רוצים להיות בשליטה לגבי ההודעות שחוזרות ללקוח. בטח שאני לא רוצה לתאר לו כל מיני דברים חסויים כאלה.
אז מה אנחנו רוצים לעשות? אנחנו רוצים להחזיר הודעת שגיאה ספציפית משלנו, ולא רק זה, אנחנו גם רוצים למנוע קריסה אמיתית בשרת. כן להחזיר חמש מאות, אבל אנחנו לא רוצים שהשרת יקרוס.
אז מה עושים? בואו נחזור לפה. ניגש ל-errors, אה, נשכפל את האחרון ל-internal server error. internal server error.
ובגלל שיש המון סוגים של כל מיני חריגות, אז אנחנו כן רוצים גם כאן לקבל message ולהעביר את זה ל-base message כאן. הנה יש לנו internal server error ספציפי שאנחנו כותבים ואנחנו רוצים לתפוס ולזרוק חריגה כזאת, לזרוק בעצם הודעת שגיאה כזאת.
בואו נלך ל-controller ומה שאנחנו צריכים לבצע זה איפה שאנחנו מבצעים route, בכל מקום שיש לנו route אנחנו יודעים שהקוד של ה-route עלול לקרוס, אז אנחנו צריכים לעטוף אותו באיזשהו try catch בצורה כזאת.
נקבל את ה-exception. אם הכול בסדר אז אנחנו מחזירים אוקיי, ואם הייתה חריגה אז אנחנו תופסים אותה. אנחנו לא נותנים למערכת לקרוס. מה שאנחנו רוצים להחזיר זה אובייקט JSON שמתאר את החריגה שהתרחשה, וזה בעצם לייצר אובייקט קודם כל מסוג JSON Result.
JSON Result זה אובייקט שאנחנו יכולים לייצר שאומר לי "תקשיב, תביא לי איזה JSON שאתה רוצה, אני אחזיר אותו ותגיד לי גם מה ה-status code שאתה רוצה להחזיר". נותן לי יותר שליטה כזאת, כי אין לנו משהו ייעודי לגבי זה.
אז נייצר JSON Result. JSON Result, הנה זה, שווה new JSON Result וניתן לו פה את האובייקט שאנחנו רוצים. האובייקט שאנחנו רוצים זה אותו אובייקט שגיאה שהיה.
בואו נייצר אותו פה וקראנו לו internal server error new. נגיד לו ex message זאת הודעת השגיאה של החריגה שהתבצעה. תן לי רק את ההודעה ואני נותן לך פה את