לזרוק Exception או להחזיר אובייקט עם הודעת שגיאה
שאלה
תשובות
-
היי
>> "זאת הדרך הנכונה לעבוד נכון (אני בשלבי לימוד) ?"
זו בדיוק הדרך הנכונה והמומלצת לרוב המקרים
זה מה שהתכונתי "שכבת השירות". בארכיטקטורה של אפליקציות אנחנו מדברים על חלוקה לשכבות ולפי חלוקה זו אתה עובד כרגע על שכבת השירות. הלקוח שיתחבר לשכבה זו באמצעות ה API יוכל להיות בעצמו שכבה נוספת של שירות ללקוחות נוספ]ים או שכבת העל שהיא שכבת ה GUI. הממשק הגרפי בו המשתמש עושה שימוש.
>> "לכן אני שואל, בפרוייקט מסוג זה, מה עדיף שאחזיר למי שמנסה לממש את השירות שלי ?"
כשעובדים על שכבת שירות נרדת אנחנו בדרך כלל לוקחים בחשבון שמיש יפנה אליה יודע לפתח ולכן אנחנו יכולים לשלוח לו Exception ולתת לו לשבור את הראש לגבי מה לעשות במקרה שהאפליקציה שלו מקבלת Exception. אני מעדיף גם במקרים כאלה לא לשלוח Exception אלא לשלוח תגובה "חוקית" שמתאימה לתגובות שאמורות להתקבל מהשרת. בהוראות שאתה מספק למי שמי שעושה שימוש ב API על מנת להתחבר לשכבת השירות אתה צריך לציין את המצבים השונים וההודעות השונות שה API עלול להחזיר. בכל קמרה גם אם מחזירים Exception וגם אם מחזיירם תגובה חוקית הרי שמי שמפתח תא האפליקציה שניגשת לשירות יצתרף לטפל בנושא. זה באחריות של אפליקציי הלקוח לטפל בשגיאות או בהודעות האלו ולא באחריות שכבת השירות.
* כמו שאמרתי זה נושא פתוח לדיון ויש מי שיעדיף לעבוד אחרת. אין כאן עניין של יותר נכון
** תחשוב על מצב בו שכבת השירות מחזירה Exception לא מצופה. אחרי הכל ייתכנו באגים כמו תמיד. ם אתה עושה שימוש ב Exception שלך אז ההפרדה יותר בעייתית מבחינת הלקוח. בשיטה שלי אני יודע ש Exception שווה לבאג! אני לא רוצה להגיע לשום מצב שיראה כ"לא מתוכנן". אני חושב שתמיד עדיף לסגור את כל האפשרויות.
*** לעומת זאת הרבה יותר קל לפתח שכבת שירות שפשוט מחזירה Exception במקרה תקלה, מכיוון שאז לא צריך API מורכב שבודק את כל האפשרויות ומספיק שהלקוח יקבל תשובה נכונה (אומר שהכל תקין) או שיקבל Exception.
>> "האם event זאת הדרך הנכונה בכלל לעשות את מה שאני רוצה ? לדווח על שגיאה שהתרחשה ?"
אני צריך להיכנס יותר לעומק כדי להגיע לכיוון כזה או אחר בנקודה זו. אם השירות נועד רק להחזיר נתון פשוט של טקסט למשל אז אני לא בטוח אני ארצה להכביד על מי שמפתח את האפליקציה שניגשת ל API. לא יותר פשוט להחזיר טקסט שכולל סימון שמדובר בשגיאה? ניתוח התוצאות זה כבר לא באחריות של שכבת השירות. מצד שני אם ה API מורכב בכל מקרה ועובד מול אובייקטים ואירועים אז הכיון של הוספת אירוע יכו להתאים מאוד לפעמים. אני לא יכול לענות על שאלה זו בלי הכיר את המערכת לעומק
[Personal Site] [Blog] [Facebook]
- סומן כתשובה על-ידי eli789 יום שני 04 אוגוסט 2014 10:17
כל התגובות
-
אהלן
זו לא שאלה של כן ולא אלא יותר ענין של תכנון ודיון על מה שמתאים לך, לכן זה פתוח וכל אחד יכול לבחור בצורה אחרת.
אני באופן דיי חד משמעי לא ממליץ על שימוש בזריקת Exception למשתמש! המשתמש לא אומר לראות שיש תקלה ואסור להגיע למצב שהתוכנה שלו נופלת. הדרך היותר טובה לדעתי היא תמיד להכין מערכת התרעות עבור המשמש ושימוש בהודעות מסודרות. לעולם לא אומרים למשתמש "היתה תקלה" אלא "חסר נתון" או "אנא בדוק את הנתונים" וכו'
כמה נקודות
1. ההודעה למשתמש חייבת להיות ברורה ולא הודעה כללית אחת לכל בעיה, כדי שהוא יוכל לטפל ולתקן.
2. בזמן הפיתוח וה QC יש לעבוד עם Exception ומחלקות DEBUG ולוודא שה כל תקין.
3. תמיד כדאי להכין לוג לכל תוכנה ולהעביר ללוג הודעות שגיאה יותר מפורטות כדי שנוכל לטפל בבעיות שיעלו כאשר המשתמש יפנה אלינו.
[Personal Site] [Blog] [Facebook]
-
רגע אני שם לב כרגע לנקודה חשובה בשאלה שלך
אתה כותב שאתה כרגע עובד על הצד של הלקוח אבל גם כותב "יבחר אם ואיך להציג בממשק שלו"
מה שכתבתי מעל נכון לגבי ה GUI משתמש. אם אתה מפתח שירות ז"א את שכבת השירות הנסתרת אז הדברים דומים אבל צריך לשים דגש על הצד של ההודעות יותר ופחו7ת הלוגים מכיוון שהלוגים בצד שלך ולא אצל הלקוח (השירות רץ אצלך בלבד, ואין לך שליה על החלק של הלקוח שהוא שכבה נוספת שהוא מפתח כניראה).
* גם במקרה זה אני מעדיף ללא Exception אבל כאן כבר הגמישות יותר גדולה ולפעמים זה אפשרי (עדיף שלא אם זה מתאים לתכנון ה API בעזרתו ניגשים לשירות)
>> עוד נקודה לאקשורה: מאוד מומלץ לעבוד עם שכבת שירות במקרה של צאט מכיוון שכך נוכל להכין בקלות גישה לשירות דרך אפליקציות מסוגים שונים ומלקוחות שונים
[Personal Site] [Blog] [Facebook]
-
היי
>> "זאת הדרך הנכונה לעבוד נכון (אני בשלבי לימוד) ?"
זו בדיוק הדרך הנכונה והמומלצת לרוב המקרים
זה מה שהתכונתי "שכבת השירות". בארכיטקטורה של אפליקציות אנחנו מדברים על חלוקה לשכבות ולפי חלוקה זו אתה עובד כרגע על שכבת השירות. הלקוח שיתחבר לשכבה זו באמצעות ה API יוכל להיות בעצמו שכבה נוספת של שירות ללקוחות נוספ]ים או שכבת העל שהיא שכבת ה GUI. הממשק הגרפי בו המשתמש עושה שימוש.
>> "לכן אני שואל, בפרוייקט מסוג זה, מה עדיף שאחזיר למי שמנסה לממש את השירות שלי ?"
כשעובדים על שכבת שירות נרדת אנחנו בדרך כלל לוקחים בחשבון שמיש יפנה אליה יודע לפתח ולכן אנחנו יכולים לשלוח לו Exception ולתת לו לשבור את הראש לגבי מה לעשות במקרה שהאפליקציה שלו מקבלת Exception. אני מעדיף גם במקרים כאלה לא לשלוח Exception אלא לשלוח תגובה "חוקית" שמתאימה לתגובות שאמורות להתקבל מהשרת. בהוראות שאתה מספק למי שמי שעושה שימוש ב API על מנת להתחבר לשכבת השירות אתה צריך לציין את המצבים השונים וההודעות השונות שה API עלול להחזיר. בכל קמרה גם אם מחזירים Exception וגם אם מחזיירם תגובה חוקית הרי שמי שמפתח תא האפליקציה שניגשת לשירות יצתרף לטפל בנושא. זה באחריות של אפליקציי הלקוח לטפל בשגיאות או בהודעות האלו ולא באחריות שכבת השירות.
* כמו שאמרתי זה נושא פתוח לדיון ויש מי שיעדיף לעבוד אחרת. אין כאן עניין של יותר נכון
** תחשוב על מצב בו שכבת השירות מחזירה Exception לא מצופה. אחרי הכל ייתכנו באגים כמו תמיד. ם אתה עושה שימוש ב Exception שלך אז ההפרדה יותר בעייתית מבחינת הלקוח. בשיטה שלי אני יודע ש Exception שווה לבאג! אני לא רוצה להגיע לשום מצב שיראה כ"לא מתוכנן". אני חושב שתמיד עדיף לסגור את כל האפשרויות.
*** לעומת זאת הרבה יותר קל לפתח שכבת שירות שפשוט מחזירה Exception במקרה תקלה, מכיוון שאז לא צריך API מורכב שבודק את כל האפשרויות ומספיק שהלקוח יקבל תשובה נכונה (אומר שהכל תקין) או שיקבל Exception.
>> "האם event זאת הדרך הנכונה בכלל לעשות את מה שאני רוצה ? לדווח על שגיאה שהתרחשה ?"
אני צריך להיכנס יותר לעומק כדי להגיע לכיוון כזה או אחר בנקודה זו. אם השירות נועד רק להחזיר נתון פשוט של טקסט למשל אז אני לא בטוח אני ארצה להכביד על מי שמפתח את האפליקציה שניגשת ל API. לא יותר פשוט להחזיר טקסט שכולל סימון שמדובר בשגיאה? ניתוח התוצאות זה כבר לא באחריות של שכבת השירות. מצד שני אם ה API מורכב בכל מקרה ועובד מול אובייקטים ואירועים אז הכיון של הוספת אירוע יכו להתאים מאוד לפעמים. אני לא יכול לענות על שאלה זו בלי הכיר את המערכת לעומק
[Personal Site] [Blog] [Facebook]
- סומן כתשובה על-ידי eli789 יום שני 04 אוגוסט 2014 10:17
-
תודה על התשובות.היי
>> "זאת הדרך הנכונה לעבוד נכון (אני בשלבי לימוד) ?"
זו בדיוק הדרך הנכונה והמומלצת לרוב המקרים
זה מה שהתכונתי "שכבת השירות". בארכיטקטורה של אפליקציות אנחנו מדברים על חלוקה לשכבות ולפי חלוקה זו אתה עובד כרגע על שכבת השירות. הלקוח שיתחבר לשכבה זו באמצעות ה API יוכל להיות בעצמו שכבה נוספת של שירות ללקוחות נוספ]ים או שכבת העל שהיא שכבת ה GUI. הממשק הגרפי בו המשתמש עושה שימוש.
>> "לכן אני שואל, בפרוייקט מסוג זה, מה עדיף שאחזיר למי שמנסה לממש את השירות שלי ?"
כשעובדים על שכבת שירות נרדת אנחנו בדרך כלל לוקחים בחשבון שמיש יפנה אליה יודע לפתח ולכן אנחנו יכולים לשלוח לו Exception ולתת לו לשבור את הראש לגבי מה לעשות במקרה שהאפליקציה שלו מקבלת Exception. אני מעדיף גם במקרים כאלה לא לשלוח Exception אלא לשלוח תגובה "חוקית" שמתאימה לתגובות שאמורות להתקבל מהשרת. בהוראות שאתה מספק למי שמי שעושה שימוש ב API על מנת להתחבר לשכבת השירות אתה צריך לציין את המצבים השונים וההודעות השונות שה API עלול להחזיר. בכל קמרה גם אם מחזירים Exception וגם אם מחזיירם תגובה חוקית הרי שמי שמפתח תא האפליקציה שניגשת לשירות יצתרף לטפל בנושא. זה באחריות של אפליקציי הלקוח לטפל בשגיאות או בהודעות האלו ולא באחריות שכבת השירות.
* כמו שאמרתי זה נושא פתוח לדיון ויש מי שיעדיף לעבוד אחרת. אין כאן עניין של יותר נכון
** תחשוב על מצב בו שכבת השירות מחזירה Exception לא מצופה. אחרי הכל ייתכנו באגים כמו תמיד. ם אתה עושה שימוש ב Exception שלך אז ההפרדה יותר בעייתית מבחינת הלקוח. בשיטה שלי אני יודע ש Exception שווה לבאג! אני לא רוצה להגיע לשום מצב שיראה כ"לא מתוכנן". אני חושב שתמיד עדיף לסגור את כל האפשרויות.
*** לעומת זאת הרבה יותר קל לפתח שכבת שירות שפשוט מחזירה Exception במקרה תקלה, מכיוון שאז לא צריך API מורכב שבודק את כל האפשרויות ומספיק שהלקוח יקבל תשובה נכונה (אומר שהכל תקין) או שיקבל Exception.
>> "האם event זאת הדרך הנכונה בכלל לעשות את מה שאני רוצה ? לדווח על שגיאה שהתרחשה ?"
אני צריך להיכנס יותר לעומק כדי להגיע לכיוון כזה או אחר בנקודה זו. אם השירות נועד רק להחזיר נתון פשוט של טקסט למשל אז אני לא בטוח אני ארצה להכביד על מי שמפתח את האפליקציה שניגשת ל API. לא יותר פשוט להחזיר טקסט שכולל סימון שמדובר בשגיאה? ניתוח התוצאות זה כבר לא באחריות של שכבת השירות. מצד שני אם ה API מורכב בכל מקרה ועובד מול אובייקטים ואירועים אז הכיון של הוספת אירוע יכו להתאים מאוד לפעמים. אני לא יכול לענות על שאלה זו בלי הכיר את המערכת לעומק
[Personal Site] [Blog] [Facebook]
אני חושב שעדיף בשלב זה, שאני עדיין עובד על התכנון, שאתקדם קצת ואולי הדברים קצת יותר יתבהרו לי.
בנתיים אחזיר Exception רגיל ואז נראה איך אני יכול לשפר את זה.
אני חושב שאלך על הכיוון של יצירת אובייקט שיכיל תיאור ידידותי של השגיאה, בלי הרבה פרטים, משהו שאפשר להציג למשתמש הסופי.
ומלבד זאת אוסיף את האובייקט של ה- Exception שהתקבל כדי שמפתח הממשק יוכל לדעת בידיוק איפה הבעיה.
אמנם לפעמים זה יכיל סתם יותר מידע, אבל זה יכול למנוע חיים קשים :)
אולי במקרים מסוימים אחזיר Exception ובמקים אחרים הודעה... אתקדם ונראה.
שוב תודה.
אעדכן בהתאם! -
בכיף :-)
זה בהחלט רעיון לא רע לבחור בדרך המהירה בשלב ראשון ותמיד אפשר לשנות במקרה הנוכחי
[Personal Site] [Blog] [Facebook]
