מצאתי כשאני קורא את הקובץ של המשתמשים יש שורה עם משתמש שגוי (ערך חסר)
בניתי את הפונקציה באופן כזה שהיא מרימה שגיאה, אבל למעשה באופן כזה אף פעם לא יצליח לי לקרוא את הקובץ ולכן לא אוכל לפענח את המסר.
אני מבין שאני צריך לבצע את הפעולה אחרת השאלה מהי הגישה הנכונה?
אני יכול כמובן להכין קובץ לוג שכאשר אני עומד בתנאי של השגיאה אז אני רושם את השורה ואת השגיאה בקובץ כזה.
השאלה אם זו הגישה הנכונה או שיש משהו אחר שניתן לעשות שהוא קצת יותר מעודן.
שים לב שרישום לקובץ לוג נועד עבור מתכנתים שאתה חולק איתם את הקוד, לא משהו שקשור למשתמש. הרעיון כאן להבנתי הוא לנהל את השגיאה כך שהקוד ידע לדלג על השורה השגויה ולהמשיך לקרוא את הקובץ למרות השגיאה.
אני לא נתקלתי בזה , אבל אם הייתי נתקל הייתי שם ערך None במקום החסר
בפונקציה load_file - בהנחחה ונגיד מגיעים לשורת מידע שלא מכילה את הנתונים הרצויים.
האם נכון יותר להרים התראה כדי שהמתכנת ידע שיש שם שורה לא תיקנית (ובכך גם להפסיק את הריצה) , או לגרום לפנקציה “לדלג” על השורות האלה אולי רק לעשות print ?
מרשה לעצמי לענות כיוון שזה יותר קשור למנהגים נכונים מאשר לפתרון –
לדעתי נכון בפונקציה פנימית להרים שגיאה, ובפונקציה שמשתמשת בה לתפוס אותה ולהמשיך הלאה
תתקן אותי אם אני טועה אבל אם אני עושה raise התכנית מפסיקה, אז אם אני מרים שגיאה בפונקציה הפנימית בכל מקרה התכנית תעצורה ולא תמשיך הלאה לא ? :\
הפונקציה הפנימית תעלה לך שגיאה (את ה-raise שיצרת).
אבל תזכור שיש את ה-Traceback.
אתה תחזור לפונקציה החיצונית עם השגיאה.
תוכל לתפוס את השגיאה שם
אה נכון נכון !! אוקי תודה לשניכם 
תקוע באותו מקום, בכל איטרציה על השורות אני בודק אם כמות האיברים היא ככמות הכותרות. הוספתי עכשיו זריקת שגיאה כשמזוהה שורה עם כמות שונה של איברים, אבל מה שקורה זה שכל יצירת הusers נעצרת ברגע קפיצת השגיאה
אתה צריך לטפל בזה גם בחוץ ואז זה יתפוס אותה (:
טיפלתי, בכל זאת כנראה שאיכשהו זה עוצר את הריצה. כנראה בגלל שאני מריץ את הפונקציה שזורקת שגיאה כחלק מlist comprehension שנמצא בreturn שלי וגורם לו להחזיר None
יש לשים לב ששימוש בraise למשל זורק שגיאה ואם אין בחוץ פונקציה שתופסת אותו הוא מפיל את הקוד
האם חובה לטפל בכל שגיאה, גם כזו שבעצם לא תתרחש בהתאם לתנאי התרגיל? אני שואל כי בקוד שלי השורה שבה חסר המידע יוצרת מילון שנכנס לרשימת המילונים כמו כל רשימה אחרת, ואין שום בעיה עם זה. כלומר, הבעיה היחידה שיכולה לצוץ זה אם המתכנת/משתמש ינסה לגשת ספציפית למילון הזה ולהשתמש בו לצורך פענוח (תסריט לא הגיוני בעליל). המילון הפגום הזה סתם יושב לו בתוך רשימת המילונים בלי להזיק לאף אחד. אני יכול לדמיין מצב שבו מישהו ירצה לעבור על כל אחד מהמילונים בלולאה כדי לחלץ מהם מידע ואם הוא מניח שכולם תקינים אז תיווצר שגיאה, אבל זה לא משהו שאמור לקרות בתרגיל. אני יכול גם כמובן לכתוב קוד שינקה את המילון ובגדול נראה שזו הפרקטיקה העדיפה - לנקות את הדאטה מראש במקום ליצור שגיאה שמישהו אחר צריך להתמודד איתה. אני יודע שכבר דנו בפרקטיקה במעלה השרשור, אבל זו נראית כמו פרקטיקה עדיפה גם מבחינה התוצר הסופי וגם מבחינת זה שעדיף לתקן שגיאות מראש מאשר להקפיץ אותן.
זה נשמע שזה בדיוק המקום בו צריכה להיות חריגה, כדי להתריע בפני המתכנת שמשהו בנתונים לא תקין
כשאתה אומר זה בדיוק המקום, הכוונה במהלך יצירת רשימת המילונים או במהלך פנייה למילון משובש?
אני חושב שהכוונה היא בזמן יצירת המילון המשובש, כי זה הרגע שבו יתגלה שמשהו פגום בדאטה, ועדיף להתריע על כך ברגע שזה מתגלה.
הטריק הוא לחשוב על עצמכם בתור המתכנת ובתור המשתמש.
עבור ממשקים פנימיים שקשורים למתכנת, שואלים:
עבור ממשקים שמונגשים כלפי המשתמש, שואלים:
איך יכול להיות שלא נתקלתי בזה??
בהגדרות של מה שהתרגיל מבקש לעשות השורה הזו לא גורמת לשגיאה. כשפותחים את הקובץ עם שמות המשתמשים ניתן לראות שיש שורה עם מידע חסר. ברוב הדרכים שבהם מחלצים את המידע בקובץ לתוך מילון כמו שהתרגיל מבקש זה לא יגרום לשום שגיאה, ומאחר ואף אחד לא מבקש מאיתנו לפנות לשורה הזו אז זה לא מקפיץ שום חריגה. אם מדפיסים את התוצאה של הפיכה למילון כחלק מהדיבגינג אז אפשר לראות את השורה הזו די בקלות. מה צריך לעשות איתה נידון פה בכמה דרכים במעלה השרשור.