עבור לתוכן

מתי משתמשים ב try-throw-catch?

Featured Replies

פורסם

האם רק להודעות שגיאה קריטיות או גם לאזהרה לא קריטית למשתמש.

למשל: המשתמש רוצה למחוק קובץ שלא קיים. האם במנגון הנ"ל או סתם הודעה על ידי IF רגיל?

וגם: מה קורה אם התרחשה שגיאה ואני רוצה לסיים את התוכנית בעקבותיה. מה לרשום ב- catch?

ועוד: לגבי מחיקת קבצים C++

א. מה ההבדל בין הפונקציה remove ולבין unlink?

ב. במה נהוג להשתמש?

פורסם

אני לא מתכנת ב C++ אבל

ה TRY הוא על מנת לנסות משהו שיכול להיכשל מסיבה שאתה לא יכול למנוע. למשל אם אתה מנסה לגשת ל DATABASE ויש איתו בעיה, אתה תקבל EXCEPTION

ולכן תופסים אותו ע"מ שהתוכנית לא תיפול וע"מ שתוכל לנהל את השגיאה בצורה המתאימה לך ביותר, בין אם לשלוח MessageBox או סתם להרים את השגיאה שלב למעלה,

לשיקולך.

ולא, לא נותנים הודעות למשתמש סתם ככה ע"י throw

, זה לא נכון לעשות

פורסם

לא בדיוק הבנתי את הקשר בין שימוש ב exceptions להודעת שגיאה למשתמש. אין שום קשר בין מה אתה מודיע למשתמש לאיך שאתה מטפל בשגיאה. מה גם שלשימוש ב exceptions אין קשר ל"חומרת" השגיאה. זו פשוט טכניקה שמציעה השפה לטיפול בשגיאות (או "חריגות") בזמן הריצה.

אם אתה שואל לגבי מתי כדאי להשתמש ב exceptions בקוד שאתה כותב, עדיף להשתמש בהן רק כשבאמת צריך (שימוש ב exceptions ל flow control נחשב לסגנון רע). בעיקרון אם הקוד שכתבת יוצר או נתקל בשגיאה (למשל רואה שקובץ לא קיים) ואתה לא יכול/רוצה/יודע לטפל בשגיאה באופן מקומי (בתוך אותה פונקציה/מחלקה וכו') אז אפשר לזרוק exception ולתפוס אותה מקוד שקרא לפונקציה.

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

זו סתם דוגמה, תקרא קצת יותר מידע על exceptions.

פורסם

תחשוב ככה, נניח אתה מנסה לכתוב קובץ לדיסק פתאום נגמר המקום, או שאתה מנסה למחוק קובץ שמשתמשים בו, במצב כזה התוכנה תזרוק exception ואם לא תתפוס אותו על ידי עטיפת קטע הקוד הספציפי הזה ב-try ו - catch אז התוכנית תקרוס, לכן אתה תעטוף אותו ב-try ו -catch ובמקרה הספציפי הזה שדיברתי עליו אתה יכול למשל להודיע למשתמש על השגיאה שהתרחשה ולבטל את הפעולה בצורה כזו שלא תגרום לתוכנית לקרוס.

מתי תשתמש ב-throw ?

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

פורסם

בקשר להערה האחרונה - לא מדויק. אתה משתמש ב-throw כאשר אתה כותב פונקציה שאתה יודע שיש לה סיכוי להיכשל, מסיבה כלשהי.

נניח, אם אתה כותב פונקציה שמתחברת ל-database, אז יש סיכוי שהחיבור ייכשל - במקרה כזה, תזרוק exception באמצעות throw, ומי שיקרא לפונקציה יצטרך לטפל בו.

פורסם

עם try-catch אתה יכול לקבל שגיאות ולשלוט בהם הרבה יותר יפה מהצורה המובנה.

אם יש לך ERROR אתה יכול לכתוב "Sorry, Program error occured" במקום הצורה המכוערת והמציקה שיש.

פורסם

עם try-catch אתה יכול לקבל שגיאות ולשלוט בהם הרבה יותר יפה מהצורה המובנה.

אם יש לך ERROR אתה יכול לכתוב "Sorry, Program error occured" במקום הצורה המכוערת והמציקה שיש.

אין שום קשר בין מה שאמרת ל-exceptions (לפחות ב-C++).

בכל מקרה, אם אתה מתחיל לעבוד עם exceptions כדאי שתקרא את: http://www.parashift.com/c++-faq-lite/exceptions.html

אם אתה ממשיך לעבוד עם exceptions, כדאי שתקרא מדי פעם את: http://www.gotw.ca/gotw/index.htm

אני רוצה לציין שלא כולם מסכימים עם הגישה של exceptions, מסיבות שונות ומשונות. דוגמא לבעיה אחת עם exceptions היא: http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx

פורסם

עם try-catch אתה יכול לקבל שגיאות ולשלוט בהם הרבה יותר יפה מהצורה המובנה.

אם יש לך ERROR אתה יכול לכתוב "Sorry, Program error occured" במקום הצורה המכוערת והמציקה שיש.

שוב, כמו שאמרתי וכמו שנאמר מעלי, אין קשר בין הדרך שבה אתה מטפל בשגיאות לבין הודעה למשתמש.

לא כל שגיאה נוצרת ע"י זריקת exception. אם למשל זיהית תו לא חוקי בתיבת טקסט אתה יכול להודיע על שגיאה למשתמש ואין לכך כל קשר לזריקת exception. גם לא על כל exception אתה בהכרח מודיע למשתמש. אתה בוחר איך ומה להודיע למשתמש ואותו זה לא מעניין איך התוכנה שלך בנויה. מוזילה למשל (בקוד שכתוב ב c++) לא משתמשים ב exceptions, יש להם מודל אחר לטיפול בשגיאות (מבוססת על קודי שגיאה). אתה בתור משתמש קצה יודע מזה? אתה מקבל הודעות פחות "מכוערות"?

גם ל exceptions יש חסרונות, כמו ביצועים למשל (בגלל הפעולה שמתבצעת על הstack בגלל זריקת ה exception). בדר"כ זה לא מפריע כי כמו השם שלהן, אתה משתמש בexceptions רק במקרה חריג, אבל שימוש מוגזם (למשל ל flow control) בעייתי יותר.

פורסם

אני לא יודע, try-catch זה מבנה שמוכר לי מJS ואני יודע שיש משהו דומה בC. חשבתי שזה אותו דבר.

פורסם

יש יותר מדי התרכזות בבעיות ביצועים של Exceptions. זה נכון שיש בעיה עם זה, אבל למעשה זה טיעון איש-קש שכן ביצועים מירביים לא חשובים להרבה תוכנות. הבעיה היא של-exception יכולות להיות השלכות חמורות של יציבות התוכנה, ועל תחזוקתיות הקוד.

BlueNosE: אני לא יודע JS, אבל אני יודע מספיק עליה כדי לדעת ש-++C ו-JS שונות מאוד.

פורסם

הבעיה היא של-exception יכולות להיות השלכות חמורות של יציבות התוכנה, ועל תחזוקתיות הקוד.

תוכל אולי להסביר איך? אולי למשל עקב exceptions שלא "נתפסים"?

פורסם

למשל exceptions שלא נתפסים, אבל זה עדיין בעיה קטנה (תמיד אפשר לעשות catch להכל).

exception-ים (איך קוראים להם בעברית?) יכולים להיזרק מכל מקום וכמעט מכל שורה, ולהתפס בהרבה מקומות. התוצאה בידיים לא זהירות עלולה להיות קוד ספגטי. למעשה כבר היו שקראו ל-exceptions בשם הלא מחמיא "structured goto".

כמו כן, קשה לכתוב קוד ++C רובוסטי בנוכחות exceptions, ולקח לקהילת ה-++C מספר שנים עד שהצליחו למצוא שיטות שיבטיחו בנייה נכונה של קוד.

בנוסף, יש את הבעיה של המחיר. המימוש של exceptions בהרבה קומפיילרים הוא לא רע, אך רחוק מלהיות מה שאתה רוצה אם יעילות זה חשוב לך. יותר גרוע מזה: במימושים שראיתי, exceptions מפרים את הכלל הידוע של C++ שאומר "אתה משלם רק על מה שאתה משתמש".

יש עוד כל מני בעיות, אבל במקום לכתוב אני אפנה למספר קישורים שמנוסחים יותר טוב ממה שאני מסוגל לו (אני גם עצלן):

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

http://www.awprofessional.com/content/images/020163371x/supplements/Exception_Handling_Article.html

מאמר של ג'ואל שמסכם את גישת ה-GOTO

http://www.joelonsoftware.com/items/2003/10/13.html

ריימונד צ'ן ממיקרוסופט:

http://blogs.msdn.com/oldnewthing/archive/2005/01/14/352949.aspx

לבסוף אני רוצה לציין שאני לא חושב ש-C++ exceptions זה משהו רע. השתמשתי ב-exceptions בעצמי לא פעם, והתוצאה הייתה קוד שלדעתי הוא קריא, יעיל ויציב. אבל צריך לדעת מה עושים, ומתי כדאי להשתמש ב-exceptions ומתי אסור.

פורסם

תודה.

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

דיונים חדשים