האם זה נוהג רע לתפוס זורק?
1. סקירה כללית
במדריך זה, נסתכל על השלכות של לתפוס זורק.
2. ה זורק מעמד
בתיעוד Java, ה- זורק מחלקה מוגדרת כ- “מעמד העל של כל השגיאות והחריגים בשפת Java“.
בואו נסתכל על ההיררכיה של ה- זורק מעמד:
ה זורק בכיתה יש שתי תת כיתות ישירות - כלומר שְׁגִיאָה ו יוצא מן הכלל שיעורים.
שְׁגִיאָה ושיעורי המשנה שלו אינם יוצאים מן הכלל, ואילו תת הכיתות של יוצא מן הכלל ניתן לבדוק חריגים או לא מסומנים.
בואו נסתכל על סוגי המצבים שתוכנית יכולה לחוות כאשר היא נכשלת.
3. מצבים הניתנים להשבה
ישנם מצבים בהם בדרך כלל התאוששות אפשרית וניתן לטפל בהם באמצעות תת-מחלקות מסומנות או לא מסומנות יוצא מן הכלל מעמד.
לדוגמה, תוכנית עשויה לרצות להשתמש בקובץ שבמקרה לא קיים במיקום שצוין, וכתוצאה מכך מסומן FileNotFoundException נזרק.
דוגמה נוספת היא התוכנית שמנסה לגשת למשאב מערכת מבלי לקבל הרשאה לעשות זאת, וכתוצאה מכך לא מסומן בקרת גישהיוצא מן הכלל נזרק.
בהתאם לתיעוד Java, ה יוצא מן הכלל class "מציין תנאים שאפליקציה סבירה עשויה לרצות לתפוס“.
4. מצבים בלתי ניתנים לשחזור
ישנם מקרים בהם תוכנית יכולה להגיע למצב בו התאוששות בלתי אפשרית במקרה של כישלון. דוגמאות נפוצות לכך הן כאשר מתרחשת הצפת מחסנית או שנגמר הזיכרון ל- JVM.
במצבים אלה ה- JVM זורק StackOverflowError ו OutOfMemoryError, בהתאמה. כפי שהציע שמותיהם, אלה הם תת-מחלקות של שְׁגִיאָה מעמד.
על פי תיעוד Java, ה שְׁגִיאָה class "מציין בעיות חמורות שאפליקציה סבירה לא צריכה לנסות לתפוס“.
5. דוגמא למצבים הניתנים להחזרה ובלתי ניתנים לשחזור
נניח שיש לנו ממשק API המאפשר למתקשרים להוסיף מזהים ייחודיים למתקן אחסון כלשהו באמצעות ה- addIDsToStorage שיטה:
class StorageAPI {public void addIDsToStorage (int קיבולת, הגדר אחסון) זורק CapacityException {if (קיבולת <1) {לזרוק CapacityException חדש ("קיבולת של פחות מ- 1 אסורה"); } ספירת int = 0; בעוד (ספירה <קיבולת) {storage.add (UUID.randomUUID (). toString ()); ספירת ++; }} // שיטות אחרות הולכות לכאן ...}מספר נקודות כשל פוטנציאליות יכולות להתרחש בעת הפעלת addIDsToStorage:
- CapacityException - תת מחלקה מסומנת של יוצא מן הכלל כשעוברים א קיבולת ערך של פחות מ -1
- NullPointerException - תת מחלקה לא מסומנת של יוצא מן הכלל אם אחסון אפס ערך מסופק במקום מופע של מַעֲרֶכֶת
- OutOfMemoryError - תת מחלקה לא מסומנת של שְׁגִיאָה אם ל- JVM אזול הזיכרון לפני היציאה מה- בזמן לוּלָאָה
ה CapacityException ו NullPointerException מצבים הם כשלים שהתוכנית יכולה להתאושש מהם, אך OutOfMemoryError הוא בלתי ניתן לשחזור.
6. לתפוס זורק
נניח שמשתמש ה- API תופס רק זורק בתוך ה נסה לתפוס כשמתקשרים addIDsToStorage:
הוסף חלל ציבורי (Storage API API, קיבולת int, הגדר אחסון) {נסה {api.addIDsToStorage (קיבולת, אחסון); } לתפוס (זורק לזריקה) {// לעשות משהו כאן}}משמעות הדבר היא שקוד החיוג מגיב באותה צורה למצבים הניתנים להחזרה ובלתי ניתנים לשחזור.
הכלל הכללי בטיפול בחריגים הוא כי נסה לתפוס החסימה חייבת להיות ספציפית ככל האפשר בכדי לתפוס חריגים. זה, יש להימנע מתרחיש של הכל.
מִדַבֵּק זורק במקרה שלנו מפר כלל כללי זה. כדי להגיב בנפרד למצבים הניתנים להחזרה ובלתי ניתנים לשחזור, קוד הקריאה יצטרך לבדוק את המקרה של ה- זורק חפץ בתוך לתפוס לַחסוֹם.
הדרך הטובה יותר תהיה להשתמש בגישה ספציפית לטיפול בחריגים ולהימנע מנסיון להתמודד עם מצבים בלתי ניתנים לשחזור.
7. מסקנה
במאמר זה בחנו את ההשלכות של תפיסה זורק ב נסה לתפוס לַחסוֹם.
כמו תמיד, קוד המקור המלא של הדוגמה זמין ב- Github.
