c# שימוש שוטף בTry/Catch

[mekev]

בהמשך לנאמר כאן (וכאן...)
שעדיף להמנע מלהשתמש ב-Try/Catch ככל האפשר

אשמח להחכים בנושא

האם אכן מומלץ גם אחרי ניפוי הקוד להמנע משימוש ב Try/Catch
ולמה

או שזה אכן חלק בלתי נפרד מהקוד השוטף
ע"מ למנוע שגיאות זמן ריצה אצל המשתמש

(אני בכלל 'דג' את השגיאות הללו, ולפי זה מעדכן את הגרסאות הבאות)

[OdedDvir]

@mekev יש הרבה מה לומר בנידון, הנה כמה נקודות:

1. רצף - זה שובר את רצף הריצה של התכנית, מעין GOTO בתחפושת, לעיני המתכנת זה מקשה מאוד על ההבנה של הקוד.
2. תחזוקה - זה מאוד מקשה על הדיבוג, בפרט בקוד אסינכרוני, חריגה יכולה לצוץ בלי שיהיה לך מושג מה גרם לה.
3. חוסר יעילות - חריגה מבזבזת משאבים מיותרים. גם אם אתה תופס אותה.
4. הסתרת באגים - אם אתה לא באמת מתכוון לטפל בשגיאה, כלומר לא רק להתעלם ממנה, אלא לעשות איתה משהו שימושי: כתיבה ללוג, התאוששות מהשגיאה על ידי בקשת קלט נוסף וכו' וחזרה למסלול הריצה הסדירה של התוכנה - השימוש ב Try/Catch לעתים קרובות נובע מחוסר ידע או מעצלות. מה שיגרום שבתוכנה יהיה את הסוג הכי בעייתי של באגים - כאלו שאף אחד לא שם לב אליהם בזמן, כי הקוד נראה כאילו הוא עובד תקין... (מכיר את המשל על מי שעקר את נורת האזהרה מלוח השעונים כי היא הפריעה לו?)
   במלים אחרות: בעת הפיתוח - אתה בעצם כן רוצה להבחין בכל החריגות ולשכתב את הקוד שלך כך שהם פשוט לא יווצרו.

חפש Why you should avoid try catch לעוד מראי מקומות מפורטים.

[Y.Excel.Access]

@OdedDvir כתבת מצוין!
הסכמתי ממש עם כל מילה (בפרט על באגים שנוצרים...), הקוד לא אמור להיות מראש עם באגים בשלב ההרצה.
ואוסיף - חלק מההבדל בין שפות עיליות לשפות נמוכות הוא שהשפות העיליות עושות לקוד כל הזמן קצת בדיקות תוך כדי הרצת התוכנה, כדי לחסוך למתכנת את זה, וזה מאט יותר. (לדוגמה - כמדומני ב C אם אתה מכניס ערך למשתנה בו יש קיבולת נמוכה הערך פשוט 'מתקזז' לתוך המשתנה הקטן יותר).

אבל, לכאורה את הגירסה ללקוח - בלבד - אכין מראש כמה TRY במקומות מועדים, אם מראש אני יודע שלא הייתי מושלם שם...
ולמה לשחרר ללקוח מוצר לא מושלם? כי לפעמים זה יעלה לו הרבה פחות שעות פיתוח כשנבחנת ההרצה בפועל - כמובן תלוי בסוג הלקוח, ברצונו ובצרכיו.

[OdedDvir]

@Y-Excel-Access כתב בc# שימוש שוטף בTry/Catch:

אם אתה מכניס ערך למשתנה בו יש קיבולת נמוכה הערך פשוט 'מתקזז' לתוך המשתנה הקטן יותר.

אם לא התכוונת בפירוש שזה יקרה - זה בעצם באג.

ולמה לשחרר ללקוח מוצר לא מושלם? כי לפעמים זה יעלה לו הרבה פחות שעות פיתוח

אני לא מסכים איתך. זה יעלה לו הרבה יותר אם לא תטפל לפחות בשגיאות שאתה יודע שלא היית מושלם שם...

[dovid]

יש פה קצת חוסר תקשורת.
Try/Catch נועד למטרת טיפול בשגיאות. כלומר אם החיים קשים, מה לעשות אז?
למשל תעשה XYZ, כתוב לקובץ, סמן את העסק כשמור. אופס.. שגיאה שהשמירה נכשלה. הטיפול הוא: הפוך חזרה את XYZ, סמן את הקובץ כלא שמור, הודע למשתמש על הבעיה והצע לו דרכי פתרון.

המפתחים משתמשים בו למטרה אחרת לגמרי: הכלת משברים. הקלט לא תקין? נו אז למה אתה עושה מזה סיפור ומקריס את הכל! תכיל את זה בשקט.

נניח יש לנו קלט שמקבל מספר דקות, ואנחנו נעשה תזכורת עוד הX דקות שהוזן.
אופס, המשתמש הכניס טקסט. בום טרח התוכנה נסגרת עם חלון נוראי של שגיאה עם כל הסודות שלנו האפלים מהקוד (שמות המשתנים...).
אז אם נעטוף את הפעולה בTry/Catch נקבל שקט תעשייתי.

אז ההוראה של @OdedDvir היא א. שאין לעשות לחלוטין את השימוש השני. ב. שגם בשימוש הראשון, במקום לבדוק בדיעבד שהקובץ לא קיים, בדוק לכתחילא. יש הרבה מקרים שאין דרך לבדוק לכתחילא, ואז Try/Catchהוא לגיטימי רק אם יש לנו רעיון מה לעשות אז. אם אנחנו רוצים להשתיק הודעת שגיאה מעצבנת יש דרך אחרת.

[צדיק תמים]

@OdedDvir כתב בc# שימוש שוטף בTry/Catch:

חוסר יעילות - חריגה מבזבזת משאבים מיותרים. גם אם אתה תופס אותה.

@dovid כתב בc# שימוש שוטף בTry/Catch:

אז ההוראה של @OdedDvir היא [...] ב. שגם בשימוש הראשון, במקום לבדוק בדיעבד שהקובץ לא קיים, בדוק לכתחילא.

זה מעניין, כי אני מכיר בפייתון שמאוד מאוד נפוץ להשתמש בטיפול בשגיאות גם כשאפשר להימנע, לדוגמה במקום לבדוק מראש שהקובץ קיים, לנסות לפתוח אותו ולטפל בשגיאה עם try/except FileNotFoundError
פעם נתקלתי בזה בהערות לתשובה בstacoverflow, והתברר לי שזה סגנון נפוץ מאוד בפייתון. אז כנראה שזה לא כ"כ חד משמעי, או שבC# זה כן חד משמעי...
https://docs.python.org/3/glossary.html#term-EAFP
https://devblogs.microsoft.com/python/idiomatic-python-eafp-versus-lbyl

[חגי]

@צדיק-תמים
ציטוט מהקישור דלעיל

Easier to ask for forgiveness than permission.

זו סתם גסות רוח של מתכנתי פייתון, אבל עם תרבות אי אפשר להתווכח. הם לא מעוניינים שתשתמש בזה בשביל הכלת שגיאות, אלא בתור תחליף לif, דוקא בדוגמה של קריאת קובץ זה רעיון מומלץ.
אם מישהו יגנוב לך את הקובץ בין הבדיקה שהוא נגיש לך ועד הקריאה שלו בפועל, אז תזרק חריגה בין כה, אז כבר עדיף לבצע ניסיון לפתוח את הקובץ בהרשאות קריאה, ולזרוק חריגה אם הניסיון כשל (או לתפוס את השגיאה ולהציג הודעה ידידותית למשתמש עם איזו תמונה מצחיקה של חתול)

(אם תסתכל באינטרנט, תראה ניסיונות של משתמשי SO לייצר פונקציית TryOpenFile בצורה בטוחה בשיטה הזו)

[dovid]

@צדיק-תמים באופן כללי, כללי תכנות הם לא לשפה מסויימת.
כללי התכנות הנכון נכתבו עם ניסיון עצום של שנים ומחקר, על ידי חוקרים שעבדו בזה כל חייהם עם המון סטטיסטיקה. יש לי בבית את הספר של Code Complete. הוא יצא לפני הרבה שנים, וכשהוציאו מהדורה מהאחרונות שלו היו שפות תכנות וטכניקות תכנות חדשות שתפסו מאוד שלא קיבלו התייחסות מספקת, אולם הוא בחר לא לשנות יותר מידי את הספר, והוא כותב בהקדמה שזה לא משנה הרבה, העקרונות נשארו אותו דבר.

אבל אכן בלינקים שהבאת, מאשרים שבפייתון זה רשמי להשתמש בלכידת שגיאות כבקרת זרימה מקומית (כלומר ממש כתחליף לif אחד ויותר). @חגי אמר שבכל מקרה תזדקק ללכידת שגיאות (בIO תמיד יכול להיות חריגות, זה לא תלוי ברצנוך הטוב), אז אתה חוסך ככה שורות קוד (ובפרט הזחות...). הם קוראים לסגנון הזה EAFP ("קל יותר לבקש סליחה מאשר לבקש רשות") לעומת LBYL ("תסתכל לפני שאתה קופץ").