NullPointerException ב-Java: הסיבות ואיך מתקנים

השגיאה הנפוצה ביותר ב-Java

NullPointerException (כולם קוראים לה NPE) קורית כשמנסים להשתמש בהפניה שמצביעה על כלום, null, כאילו היא מצביעה על אובייקט אמיתי. משתנים ב-Java מטיפוס אובייקט מחזיקים או אובייקט או null, הערך שאומר "אין כאן אובייקט". ברגע שמבקשים מ-null לעשות משהו, לקרוא עליו למתודה, לקרוא אחד מהשדות שלו, לגשת אליו לפי אינדקס, אין שם על מה לפעול, וה-JVM זורקת חריגה.

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

public class Main {
    public static void main(String[] args) {
        String name = null;
        System.out.println(name.length());  // בום: name הוא null
    }
}

אין String ש-length() יכולה לרוץ עליו, ולכן התוכנית נעצרת עם NullPointerException.

קריאת ההודעה

מאז Java 14, ההודעה אומרת לכם בדיוק מה היה null, וזה נקרא Helpful NullPointerException. קראו אותה לפני שאתם משנים משהו:

Exception in thread "main" java.lang.NullPointerException: Cannot invoke "String.length()" because "name" is null
	at Main.main(Main.java:4)

שני חלקים חשובים. Cannot invoke "String.length()" היא הפעולה שנכשלה, ו-because "name" is null מצביע על האשם. השורה at Main.main(Main.java:4) היא ה-stack trace שמצביע על השורה המדויקת. לכן התיקון הוא לא "לעטוף את שורה 4 ב-try", אלא "להבין למה name הוא null בשורה 4". כמעט תמיד הבאג נמצא מוקדם יותר, במקום שבו הערך היה צריך להיות מושם ולא הושם.

הדרכים לגרום לה

NPE מגיעות מקומץ פעולות, וכולן וריאציות על "נגיעה ב-null":

import java.util.HashMap;
import java.util.Map;

public class Main {
    public static void main(String[] args) {
        // 1. קריאה למתודה על null
        String s = null;
        // System.out.println(s.toUpperCase());  // NPE

        // 2. חיפוש במפה שלא מצא מחזיר null
        Map<String, Integer> ages = new HashMap<>();
        Integer age = ages.get("Ada");   // אין מפתח כזה -> null
        System.out.println("Lookup returned: " + age);

        // 3. unboxing של wrapper שהוא null לטיפוס פרימיטיבי
        // int n = age;   // NPE: אי אפשר לבצע unboxing ל-Integer שהוא null לתוך int

        System.out.println("Reached the end safely");
    }
}

חיפושים במפה הם מקור קלאסי: get מחזירה null כשהמפתח לא קיים, וה-NPE צצה לעיתים קרובות כמה שורות אחר כך, כשסוף סוף משתמשים בערך. Unboxing הוא המקרה הערמומי: השמה של Integer שהוא null ל-int זורקת חריגה, כי אין מספר להעתיק.

הגנה עם בדיקת null

ההגנה הפשוטה ביותר היא if שמוודא שהפניה אינה null לפני שמשתמשים בה:

public class Main {
    public static void main(String[] args) {
        String name = lookupName(7);

        if (name != null) {
            System.out.println(name.toUpperCase());
        } else {
            System.out.println("No name found");
        }
    }

    static String lookupName(int id) {
        return null;  // נניח שהחיפוש לא מצא כלום
    }
}

כשמשווים משתנה ל-String קבוע, שימו את הקבוע ראשון: "yes".equals(answer) במקום answer.equals("yes"). אם answer הוא null, הצורה הראשונה מחזירה false בשקט, והשנייה זורקת חריגה.

public class Main {
    public static void main(String[] args) {
        String answer = null;

        // בטוח גם כש-answer הוא null:
        System.out.println("yes".equals(answer));   // false, בלי NPE

        // answer.equals("yes") כאן היה זורק NullPointerException
    }
}

להיכשל מהר עם Objects.requireNonNull

פיזור בדיקות null בכל מקום נהיה רועש. כשערך אף פעם לא אמור להיות null, למשל ארגומנט של בנאי, בודקים אותו בגבול עם Objects.requireNonNull. היא זורקת חריגה מיד, עם הודעה ברורה, בנקודה שבה הערך הבעייתי מגיע, במקום עמוק בתוך הקוד מאוחר יותר:

import java.util.Objects;

public class Main {
    public static void main(String[] args) {
        try {
            new Account(null);
        } catch (NullPointerException e) {
            System.out.println("Rejected: " + e.getMessage());
        }
    }

    static class Account {
        final String owner;

        Account(String owner) {
            this.owner = Objects.requireNonNull(owner, "owner must not be null");
        }
    }
}

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

להימנע מ-null מלכתחילה

ה-NPE הטובה ביותר היא זו שלא יכולה לקרות, כי אין null להיתקל בו. כמה הרגלים עושים הבדל גדול:

• החזירו אוסף ריק או מחרוזת ריקה, אף פעם לא null. על Collections.emptyList() ועל "" בטוח לעבור בלולאה ולקרוא למתודות.
• השתמשו ב-getOrDefault במפות, כדי שחיפוש שלא מצא יחזיר ערך אמיתי במקום null.
• אתחלו שדות כשמצהירים עליהם, במקום להשאיר אותם null עד "אחר כך".

import java.util.HashMap;
import java.util.Map;

public class Main {
    public static void main(String[] args) {
        Map<String, Integer> ages = new HashMap<>();
        ages.put("Ada", 36);

        // בלי null, בלי סיכון לבעיות unboxing:
        int boris = ages.getOrDefault("Boris", 0);
        System.out.println("Boris: " + boris);
    }
}

כשערך הוא אופציונלי באמת, חיפוש שבאופן לגיטימי עשוי לא למצוא כלום, Java מציעה את Optional, מיכל שמכריח את הקורא לטפל במקרה של "אין ערך" במקום להחזיר null בשקט. זה הנושא הקשור שכדאי לקרוא הבא אם רוצים לתכנן את החורים האלה החוצה מה-API שלכם לגמרי.

לסיכום

NullPointerException היא הדרך של Java לומר לכם שהשתמשתם בהפניה שמחזיקה null כאילו היא מחזיקה אובייקט. התיקון הוא לעיתים רחוקות לתפוס אותה: קוראים את ההודעה המפורטת, עוקבים אחורה למקום שבו הערך היה צריך להיקבע, ואז מבטיחים שהוא לא null או מגינים על המקום שבו משתמשים בו. היעזרו ב-Objects.requireNonNull כדי להיכשל מהר בגבולות, העדיפו ערכים ריקים ו-getOrDefault על פני null, והשתמשו ב-Optional כשהיעדר ערך הוא תוצאה אמיתית וצפויה. אמצו את צורת החשיבה הזו, והשגיאה הנפוצה ביותר ב-Java תהפוך לאחת הנדירות ביותר בקוד שלכם.