IllegalArgumentException או NullPointerException עבור פרמטר Null?
1. הקדמה
בין ההחלטות שאנו מקבלים בעת כתיבת היישומים שלנו, רבים נוגעים מתי לזרוק חריגים ואיזה סוג לזרוק.
במדריך מהיר זה, אנו נתמודד עם הנושא של איזה יוצא מן הכלל לזרוק כשמישהו עובר ריק פרמטר לאחת מהשיטות שלנו: IllegalArgumentException אוֹ NullPointerException.
נבדוק את הנושא על ידי בחינת הטיעונים לשני הצדדים.
2. IllegalArgumentException
ראשית, בואו נסתכל על הטיעונים לזריקת IllegalArgumentException.
בואו ניצור שיטה פשוטה שזורקת IllegalArgumentException כאשר עבר א ריק:
תהליך הריק הציבוריSomethingNotNull (אובייקט myParameter) {אם (myParameter == null) {זרוק IllegalArgumentException חדש ("הפרמטר 'myParameter' לא יכול להיות ריק"); }}עכשיו, בואו נעבור לטיעונים לטובת IllegalArgumentException.
2.1. כך אומר ג'אדוק להשתמש בו
כשאנחנו קוראים את Javadoc עבור IllegalArgumentException, זה אומר זה לשימוש כאשר ערך לא חוקי או לא הולם מועבר לשיטה. אנו יכולים לשקול א ריק להתנגד להיות לא חוקי או בלתי הולם אם השיטה שלנו לא מצפה לזה, וזה יהיה יוצא מן הכלל מתאים לזרוק אותנו.
2.2. זה תואם את הציפיות למפתחים
לאחר מכן, בואו נחשוב כיצד אנו, כמפתחים, חושבים כשאנחנו רואים עקבות מחסנית ביישומים שלנו. תרחיש נפוץ מאוד בו אנו מקבלים א NullPointerException כאשר ניסינו לגשת בטעות ל- a ריק לְהִתְנַגֵד. במקרה זה אנו הולכים להיכנס עמוק ככל האפשר כדי לראות למה אנו מתייחסים ריק.
כשאנחנו מקבלים IllegalArgumentException, אנו עשויים להניח שאנחנו מעבירים משהו לא בסדר לשיטה. במקרה זה, נחפש בערימה את השיטה התחתונה ביותר אליה אנו קוראים ונתחיל את הבאגים שלנו משם. אם ניקח בחשבון דרך חשיבה זו, ה IllegalArgumentException הולך להכניס אותנו לערימה שלנו למקום שבו נעשית הטעות.
2.3. ויכוחים אחרים
לפני שנמשיך לטיעונים עבור NullPointerExceptionבואו נסתכל על כמה נקודות קטנות יותר לטובת IllegalArgumentException. יש מפתחים שמרגישים שרק ה- JDK צריך לזרוק NullPointerException. כפי שנראה בחלק הבא, ה- Javadoc אינו תומך בתיאוריה זו. טענה נוספת היא שזה יותר עקבי לשימוש IllegalArgumentException מכיוון שבזה נשתמש בערכי פרמטרים לא חוקיים אחרים.
3. NullPointerException
לאחר מכן, הבה נבחן את הטיעונים עבור NullPointerException.
בואו ניצור דוגמה שזורקת א NullPointerException:
תהליך הריק הציבוריSomethingElseNotNull (אובייקט myParameter) {אם (myParameter == null) {זרוק NullPointerException חדש ("פרמטר 'myParameter' לא יכול להיות ריק"); }}3.1. כך אומר ג'אדוק להשתמש בו
על פי ה- Javadoc עבור NullPointerException, NullPointerException נועד לשמש לניסיון להשתמש ריק היכן שנדרש אובייקט. אם פרמטר השיטה שלנו לא נועד להיות ריקאז יכולנו לשקול זאת באופן סביר כחפץ הנדרש ולהשליך את NullPointerException.
3.2. זה תואם ל- API של JDK
בואו נקדיש רגע לחשוב על רבות משיטות ה- JDK הנפוצות שאנו מכנים במהלך הפיתוח. רבים מהם זורקים א NullPointerException אם אנו מספקים א ריק. בנוסף, Objects.requireNonNull () זורק א NullPointerException אם נעבור פנימה ריק. על פי חפצים תיעוד, הוא קיים בעיקר לאימות פרמטרים.
בנוסף לשיטות JDK שזורקות NullPointerException, אנו יכולים למצוא דוגמאות אחרות לסוגי חריגים ספציפיים שנזרקים משיטות בממשק ה- API של Collections. ArrayList.addAll (אינדקס, אוסף) זורק IndexOutOfBoundsException אם האינדקס נמצא מחוץ לגודל הרשימה וזורק a NullPointerException אם האוסף הוא ריק. אלה שני סוגים חריגים מאוד ספציפיים ולא הגנריים יותר IllegalArgumentException.
יכולנו לשקול IllegalArgumentException להיות מיועד למקרים בהם אין לנו סוג חריג ספציפי יותר.
4. מסקנה
כפי שראינו במדריך זה, זו שאלה שאין לה תשובה ברורה. נראה שהתיעוד לשני יוצאי הדופן חופף בכך שכאשר הם לוקחים לבד, שניהם נשמעים מתאימים. יש גם טיעונים משכנעים נוספים לשני הצדדים המבוססים על האופן שבו מפתחים מבצעים ניפוי באגים שלהם ועל פי דפוסים שנראים בשיטות JDK עצמם.
בכל חריג שבחרנו, עלינו להיות עקביים בכל היישום שלנו. בנוסף, אנו יכולים להפוך את החריגים שלנו לשימושיים יותר על ידי מתן מידע משמעותי לבנאי החריגים. לדוגמא, יהיה קל יותר לפתור את האפליקציות שלנו אם נספק את שם הפרמטר בהודעת החריג.
כמו תמיד, קוד הדוגמה זמין ב- GitHub.
