ทำไมต้องโยน NullPointerException อย่างชัดเจนแทนที่จะปล่อยให้มันเกิดขึ้นเองตามธรรมชาติ?

เมื่ออ่านซอร์สโค้ดของ JDK ฉันพบว่าเป็นเรื่องธรรมดาที่ผู้เขียนจะตรวจสอบพารามิเตอร์ว่าเป็นโมฆะหรือไม่จากนั้นให้โยน NullPointerException () ใหม่ด้วยตนเอง ทำไมพวกเขาทำมัน ฉันคิดว่าไม่จำเป็นต้องทำเช่นนั้นเพราะมันจะโยน NullPointerException ใหม่ () เมื่อเรียกวิธีการใด ๆ (นี่คือซอร์สโค้ดของ HashMap ตัวอย่างเช่น :)

public V computeIfPresent(K key,
                          BiFunction<? super K, ? super V, ? extends V> remappingFunction) {
    if (remappingFunction == null)
        throw new NullPointerException();
    Node<K,V> e; V oldValue;
    int hash = hash(key);
    if ((e = getNode(hash, key)) != null &&
        (oldValue = e.value) != null) {
        V v = remappingFunction.apply(key, oldValue);
        if (v != null) {
            e.value = v;
            afterNodeAccess(e);
            return v;
        }
        else
            removeNode(hash, key, null, false, true);
    }
    return null;
}

มีเหตุผลหลายประการที่นึกขึ้นมาได้หลายอย่างเกี่ยวข้องกันอย่างใกล้ชิด:

ล้มเหลวอย่างรวดเร็ว:ถ้ามันกำลังจะล้มเหลวดีที่สุดที่จะล้มเหลวเร็วกว่าในภายหลัง สิ่งนี้ทำให้เกิดปัญหาในการใกล้ชิดกับแหล่งที่มาทำให้ง่ายต่อการระบุและกู้คืนจาก นอกจากนี้ยังหลีกเลี่ยงการสูญเสียรอบการทำงานของ CPU ในรหัสที่ผูกไว้กับความล้มเหลว

เจตนา: การโยนข้อยกเว้นอย่างชัดเจนทำให้ผู้ดูแลเห็นว่ามีข้อผิดพลาดอย่างจงใจและผู้เขียนก็ตระหนักถึงผลที่จะตามมา

ความสอดคล้อง:หากข้อผิดพลาดได้รับอนุญาตให้เกิดขึ้นตามธรรมชาติมันอาจไม่เกิดขึ้นในทุกสถานการณ์ หากไม่พบการจับคู่ตัวอย่างremappingFunctionจะไม่ถูกใช้และข้อยกเว้นจะไม่ถูกส่งออกไป การตรวจสอบความถูกต้องของอินพุตล่วงหน้าจะช่วยให้สามารถกำหนดพฤติกรรมและกำหนดเอกสารที่ชัดเจนยิ่งขึ้นได้

ความเสถียร:รหัสวิวัฒนาการตลอดเวลา รหัสที่พบข้อยกเว้นตามธรรมชาติอาจเกิดขึ้นอีกครั้งหลังจากการปรับโครงสร้างเล็กน้อยหยุดทำเช่นนั้นหรือทำภายใต้สถานการณ์ที่แตกต่างกัน การขว้างมันอย่างชัดเจนทำให้มีโอกาสน้อยที่พฤติกรรมจะเปลี่ยนโดยไม่ตั้งใจ

มันมีไว้เพื่อความชัดเจนความสม่ำเสมอและเพื่อป้องกันการทำงานที่ไม่จำเป็นและไม่จำเป็น

พิจารณาสิ่งที่จะเกิดขึ้นหากไม่มีส่วนคำสั่งที่ด้านบนของวิธีการ มันจะโทรหาเสมอhash(key)และgetNode(hash, key)แม้กระทั่งเมื่อnullผ่านเข้าremappingFunctionมาก่อนที่ NPE จะถูกโยนทิ้งไป

ยิ่งแย่ไปกว่านั้นถ้าifเงื่อนไขเป็นเช่นfalseนั้นเราก็เอาelseสาขาซึ่งไม่ได้ใช้remappingFunctionเลยซึ่งหมายความว่าวิธีการไม่ได้โยน NPE เสมอเมื่อ a nullผ่าน; ไม่ว่าจะขึ้นอยู่กับสถานะของแผนที่

สถานการณ์ทั้งสองไม่ดี หากnullไม่ใช่ค่าที่ถูกต้องสำหรับremappingFunctionวิธีการนั้นควรโยนข้อยกเว้นอย่างสม่ำเสมอโดยไม่คำนึงถึงสถานะภายในของวัตถุในขณะที่มีการโทรและควรทำเช่นนั้นโดยไม่ต้องทำงานที่ไม่จำเป็นซึ่งไม่มีจุดหมายเพราะมันกำลังจะโยน ในที่สุดมันเป็นหลักการที่ดีในการทำความสะอาดโค้ดที่ชัดเจนเพื่อให้มีการ์ดป้องกันอยู่ด้านหน้าเพื่อให้ทุกคนที่ดูซอร์สโค้ดสามารถเห็นว่ามันจะทำ

แม้ว่าข้อยกเว้นจะถูกโยนในขณะนี้โดยรหัสทุกสาขาเป็นไปได้ว่าการแก้ไขในอนาคตของรหัสจะเปลี่ยนไป การตรวจสอบที่จุดเริ่มต้นทำให้แน่ใจว่าจะดำเนินการอย่างแน่นอน

นอกเหนือจากเหตุผลที่ระบุไว้โดยคำตอบที่ยอดเยี่ยมของ @ shmosel ...

ประสิทธิภาพการทำงาน:อาจมี / ได้รับประโยชน์ด้านประสิทธิภาพ (ใน JVM บางตัว) เพื่อโยน NPE อย่างชัดเจนแทนที่จะปล่อยให้ JVM ทำ

ขึ้นอยู่กับกลยุทธ์ที่ล่าม Java และคอมไพเลอร์ JIT ใช้ในการตรวจสอบการกระจายของพอยน์เตอร์พอยน์เตอร์ กลยุทธ์หนึ่งคือการไม่ทดสอบว่าง แต่ให้ดักจับ SIGSEGV ที่เกิดขึ้นเมื่อคำสั่งพยายามเข้าถึงที่อยู่ 0 นี่เป็นวิธีที่เร็วที่สุดในกรณีที่การอ้างอิงนั้นถูกต้องเสมอ แต่มีราคาแพงในกรณี NPE

การทดสอบอย่างชัดเจนสำหรับnullในรหัสจะหลีกเลี่ยงประสิทธิภาพการทำงาน SIGSEGV ในสถานการณ์ที่ NPEs เกิดขึ้นบ่อยครั้ง

(ฉันสงสัยว่านี่จะเป็นการเพิ่มประสิทธิภาพขนาดเล็กที่คุ้มค่าใน JVM สมัยใหม่ แต่อาจเป็นในอดีต)

ความเข้ากันได้:เหตุผลที่เป็นไปได้ที่ไม่มีข้อความในข้อยกเว้นคือเพื่อความเข้ากันได้กับ NPEs ที่ถูกโยนโดย JVM เอง ในการปรับใช้ Java ที่สอดคล้องกับ NPE ที่ส่งออกโดย JVM มีnullข้อความ (Android Java แตกต่างกัน)

นอกเหนือจากสิ่งที่คนอื่น ๆ ชี้ให้เห็นแล้วมันก็คุ้มค่าที่จะได้เห็นบทบาทของการประชุมที่นี่ ยกตัวอย่างเช่นใน C # คุณมีแบบแผนเดียวกันในการเพิ่มข้อยกเว้นอย่างชัดเจนในกรณีเช่นนี้ แต่เป็นแบบเฉพาะเจาะจงArgumentNullExceptionซึ่งค่อนข้างเจาะจงกว่า (C # การประชุมคือการที่NullReferenceException มักจะแสดงให้เห็นถึงข้อผิดพลาดบางชนิด - มากเพียงมันไม่ควรที่เคยเกิดขึ้นในรหัสการผลิตที่ได้รับArgumentNullExceptionมักจะไม่เหมือนกัน แต่มันอาจจะเป็นข้อผิดพลาดมากขึ้นตามแนวของ "คุณทำไม่ได้ เข้าใจวิธีการใช้ไลบรารีอย่างถูกต้อง "ชนิดของบั๊ก)

ดังนั้นโดยทั่วไปใน C # NullReferenceExceptionหมายความว่าโปรแกรมของคุณพยายามใช้จริง ๆ ในขณะที่ArgumentNullExceptionมันหมายความว่ามันรับรู้ว่าค่านั้นผิดและไม่ต้องกังวลที่จะใช้มัน ความจริงแล้วอาจแตกต่างกัน (ขึ้นอยู่กับสถานการณ์) เพราะArgumentNullExceptionหมายความว่าวิธีการที่เป็นปัญหายังไม่มีผลข้างเคียง (เนื่องจากไม่สามารถกำหนดเงื่อนไขได้ล่วงหน้า)

อนึ่งหากคุณกำลังเพิ่มบางอย่างเช่นArgumentNullExceptionหรือIllegalArgumentExceptionนั่นเป็นส่วนหนึ่งของการตรวจสอบ: คุณต้องการข้อยกเว้นที่แตกต่างจากที่คุณได้รับ "ปกติ"

ไม่ว่าจะด้วยวิธีใดการเพิ่มข้อยกเว้นอย่างชัดเจนจะเป็นการตอกย้ำแนวปฏิบัติที่ดีเกี่ยวกับความชัดเจนของเงื่อนไขและข้อโต้แย้งที่คาดการณ์ไว้ของวิธีการของคุณ หากคุณไม่ได้ตรวจสอบอย่างชัดเจนnullฉันไม่รู้ว่าเป็นเพราะคุณคิดว่าจะไม่มีใครnullทะเลาะกันเลยคุณกำลังนับให้โยนข้อยกเว้นอยู่ดีหรือคุณลืมตรวจสอบ

มันเป็นเช่นนั้นคุณจะได้รับการยกเว้นทันทีที่คุณทำผิดพลาดแทนที่จะทำในภายหลังเมื่อคุณใช้แผนที่และไม่เข้าใจว่าทำไมมันเกิดขึ้น

มันจะเปลี่ยนเงื่อนไขข้อผิดพลาดที่ดูเหมือนผิดพลาดไปสู่การละเมิดสัญญาที่ชัดเจน: ฟังก์ชั่นมีเงื่อนไขเบื้องต้นบางประการสำหรับการทำงานอย่างถูกต้องดังนั้นจึงตรวจสอบก่อนล่วงหน้าบังคับให้พบ

ผลคือคุณจะไม่ต้องแก้ไขข้อบกพร่องcomputeIfPresent()เมื่อคุณได้รับการยกเว้นจากมัน เมื่อคุณเห็นว่าข้อยกเว้นมาจากการตรวจสอบเงื่อนไขเบื้องต้นคุณจะรู้ว่าคุณเรียกฟังก์ชันนี้ว่ามีข้อโต้แย้งที่ผิดกฎหมาย หากการตรวจสอบไม่ได้อยู่ที่นั่นคุณจะต้องยกเว้นความเป็นไปได้ว่ามีข้อผิดพลาดบางอย่างภายในcomputeIfPresent()ตัวเองที่นำไปสู่ข้อยกเว้นที่ถูกโยน

เห็นได้ชัดว่าการขว้างนายพลNullPointerExceptionเป็นทางเลือกที่แย่จริงๆเพราะมันไม่ได้ส่งสัญญาณการละเมิดสัญญาในตัวของมันเอง IllegalArgumentExceptionจะเป็นทางเลือกที่ดีกว่า

Sidenote:
ฉันไม่รู้ว่า Java อนุญาตให้ใช้ (ฉันสงสัยหรือไม่) แต่โปรแกรมเมอร์ C / C ++ ใช้assert()ในกรณีนี้ซึ่งดีกว่าอย่างมากสำหรับการดีบัก: มันบอกให้โปรแกรมหยุดทำงานทันทีและยากที่สุดเท่าที่จะทำได้ ประเมินสภาพเป็นเท็จ ดังนั้นถ้าคุณวิ่ง

void MyClass_foo(MyClass* me, int (*someFunction)(int)) {
    assert(me);
    assert(someFunction);

    ...
}

ภายใต้ดีบักเกอร์และบางสิ่งที่ส่งผ่านไปNULLยังอาร์กิวเมนต์ทั้งสองโปรแกรมจะหยุดทันทีที่บรรทัดบอกว่าอาร์กิวเมนต์ใดเป็นNULLและคุณจะสามารถตรวจสอบตัวแปรท้องถิ่นทั้งหมดของ call stack ทั้งหมดในเวลาว่าง

เป็นเพราะมันเป็นไปได้ที่จะไม่เกิดขึ้นตามธรรมชาติ ลองดูรหัสชิ้นนี้:

bool isUserAMoron(User user) {
    Connection c = UnstableDatabase.getConnection();
    if (user.name == "Moron") { 
      // In this case we don't need to connect to DB
      return true;
    } else {
      return c.makeMoronishCheck(user.id);
    }
}

(แน่นอนว่ามีปัญหามากมายในตัวอย่างนี้เกี่ยวกับคุณภาพของรหัสขออภัยที่ขี้เกียจจินตนาการตัวอย่างที่สมบูรณ์แบบ)

สถานการณ์ที่cจะไม่ถูกใช้จริงและNullPointerExceptionจะไม่ถูกโยนแม้ว่าc == nullจะเป็นไปได้

ในสถานการณ์ที่ซับซ้อนมากขึ้นมันจะไม่ใช่เรื่องง่ายที่จะตามล่าคดีดังกล่าว นี่คือเหตุผลว่าทำไมเช็คทั่วไปถึงif (c == null) throw new NullPointerException()ดีกว่า

มันมีจุดประสงค์เพื่อป้องกันความเสียหายเพิ่มเติมหรือเข้าสู่สถานะที่ไม่สอดคล้องกัน

นอกเหนือจากคำตอบที่ยอดเยี่ยมอื่น ๆ ทั้งหมดที่นี่ฉันยังต้องการเพิ่มบางกรณี

คุณสามารถเพิ่มข้อความหากคุณสร้างข้อยกเว้นของคุณเอง

หากคุณโยนของคุณเองNullPointerExceptionคุณสามารถเพิ่มข้อความ (ซึ่งคุณควรแน่นอน!)

ข้อความเริ่มต้นเป็นnullจากและทุกวิธีการที่จะใช้มันตัวอย่างเช่นnew NullPointerException() Objects.requireNonNullหากคุณพิมพ์ null นั้นมันสามารถแปลเป็นสตริงว่าง ...

ค่อนข้างสั้นและไม่เป็นทางการ ...

การติดตามสแต็กจะให้ข้อมูลจำนวนมาก แต่สำหรับผู้ใช้ที่จะรู้ว่าอะไรเป็นโมฆะพวกเขาต้องขุดรหัสและดูแถวที่แน่นอน

ตอนนี้ลองนึกภาพว่า NPE ถูกห่อหุ้มและส่งผ่านเน็ตเช่นเป็นข้อความในข้อผิดพลาดของบริการบนเว็บบางทีระหว่างแผนกหรือองค์กร สถานการณ์กรณีที่เลวร้ายที่สุดไม่มีใครคิดว่าสิ่งใดที่nullเหมาะสมกับ ...

การโทรวิธีการรับสายจะทำให้คุณคาดเดาได้

ข้อยกเว้นจะบอกให้คุณทราบในข้อยกเว้นที่เกิดขึ้น พิจารณาแถวต่อไปนี้:

repository.getService(someObject.someMethod());

ถ้าคุณได้ NPE และมันชี้ไปที่แถวนี้อันใดอันหนึ่งrepositoryและsomeObjectว่างเปล่า

แต่การตรวจสอบตัวแปรเหล่านี้เมื่อคุณได้รับอย่างน้อยจะชี้ไปที่แถวที่พวกเขาหวังว่าจะเป็นตัวแปรเดียวที่ถูกจัดการ และดังที่กล่าวไว้ก่อนหน้านี้ดียิ่งขึ้นถ้าข้อความแสดงข้อผิดพลาดของคุณมีชื่อของตัวแปรหรือคล้ายกัน

ข้อผิดพลาดเมื่อประมวลผลอินพุตจำนวนมากควรให้ข้อมูลที่ระบุตัวตน

ลองนึกภาพว่าโปรแกรมของคุณกำลังประมวลผลไฟล์อินพุตด้วยหลายพันแถวและทันใดนั้นก็มี NullPointerException คุณมองไปที่สถานที่และตระหนักว่าการป้อนข้อมูลบางอย่างไม่ถูกต้อง ... สิ่งที่ท่าน? คุณจะต้องการข้อมูลเพิ่มเติมเกี่ยวกับหมายเลขแถวบางทีคอลัมน์หรือข้อความแถวทั้งหมดเพื่อทำความเข้าใจว่าแถวใดในไฟล์นั้นจำเป็นต้องแก้ไข