ตรวจสอบข้อผิดพลาดรันไทม์ของ Java

Feb 26 2023

ภาพรวมคร่าวๆ ของ Java Runtime Errors · Runtime Errors ใน Java คืออะไร · Runtime Error VS Compile-Time Errors · Types of Runtime Errors · How are runtime error appeared? ตรวจหาข้อยกเว้นรันไทม์· ตัวอย่างข้อผิดพลาดรันไทม์ ข้อผิดพลาดรันไทม์ใน Java คืออะไร ข้อผิดพลาดที่เกิดขึ้นในขณะดำเนินการโปรแกรมเรียกว่าข้อผิดพลาดรันไทม์ ข้อผิดพลาดประเภทนี้ไม่สามารถตรวจพบได้ในขณะคอมไพล์ เนื่องจากไม่มีข้อผิดพลาดในไวยากรณ์

ภาพรวมโดยย่อของ Java Runtime Errors

· Runtime Errors ใน Java คืออะไร?
· ข้อผิดพลาดรันไทม์ VS ข้อผิดพลาดเวลาคอมไพล์
· ประเภทของข้อผิดพลาดรันไทม์
· ข้อผิดพลาดรันไทม์ปรากฏขึ้นอย่างไร
· ฉันต้องโยนข้อผิดพลาดรันไทม์หรือไม่
· เกิดอะไรขึ้นเมื่อคุณไม่พบข้อยกเว้นรันไทม์
· ตัวอย่างข้อผิดพลาดรันไทม์

ข้อผิดพลาดรันไทม์ใน Java คืออะไร

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

คอมไพเลอร์ Java ตรวจไม่พบข้อผิดพลาดรันไทม์เนื่องจากคอมไพเลอร์ Java ไม่มีเทคนิคใด ๆ ในการตรวจจับข้อผิดพลาดเหล่านี้ เนื่องจากไม่มีข้อมูลรันไทม์ทั้งหมดที่พร้อมใช้งาน ข้อผิดพลาดรันไทม์ถูกจับโดยJava Virtual Machine (JVM) เมื่อโปรแกรมกำลังทำงาน

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

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

ข้อผิดพลาดรันไทม์ VS ข้อผิดพลาดเวลาคอมไพล์

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

การตรวจจับ

คอมไพเลอร์สามารถตรวจจับข้อผิดพลาดเวลาคอมไพล์ได้อย่างง่ายดายในระหว่างการพัฒนาโค้ด คอมไพเลอร์ไม่สามารถตรวจจับข้อผิดพลาดรันไทม์ได้อย่างง่ายดาย ดังนั้นเราจึงจำเป็นต้องระบุในระหว่างการดำเนินการโค้ด

อ้างอิง

ข้อผิดพลาดเวลาคอมไพล์โดยทั่วไปหมายถึงข้อผิดพลาดที่สอดคล้องกับความหมายหรือไวยากรณ์ ข้อผิดพลาดรันไทม์หมายถึงข้อผิดพลาดที่คอมไพเลอร์ตรวจไม่พบ แต่เราพบข้อผิดพลาดเหล่านี้ระหว่างการดำเนินการโค้ด (ระหว่างรันไทม์)

ผลกระทบ

ข้อผิดพลาดในการคอมไพล์เวลาคือ ข้อผิดพลาด ทางความหมายหรือไวยากรณ์ซึ่งจะป้องกันไม่ให้โค้ดทำงาน (การคอมไพล์) เนื่องจากตรวจพบข้อผิดพลาดทางไวยากรณ์ Wheares Runtime Errors ทำให้โค้ดไม่สามารถดำเนินการได้อย่างสมบูรณ์

การตรึง

เราสามารถแก้ไขข้อผิดพลาดเวลาคอมไพล์ระหว่างการพัฒนาโค้ดได้อย่างง่ายดาย คอมไพเลอร์ไม่สามารถระบุข้อผิดพลาดรันไทม์ได้ แต่เราสามารถแก้ไขได้หลังจากการรันโค้ดและการระบุโค้ดในครั้งก่อน

ประเภทของข้อผิดพลาดรันไทม์

มีข้อผิดพลาดรันไทม์หลายประเภทที่เราสามารถพบเจอได้ในขณะดำเนินการโปรแกรม ข้อผิดพลาดรันไทม์ที่พบบ่อยบางส่วนแสดงอยู่ด้านล่าง:

ข้อผิดพลาดในการป้อนข้อมูล : ข้อผิดพลาดอินพุตและเอาต์พุต

มีวิธีนับไม่ถ้วนที่ผู้ใช้ป้อนอาจทำให้แอปพลิเคชันเสียหายได้

บนกระดานความคิดเห็นที่ใช้ HTML ผู้ใช้ที่ได้รับอนุญาตให้ส่งเครื่องหมายน้อยกว่า (<) หรือมากกว่า (>) ที่ไม่ได้เข้ารหัสอาจทำลายความสามารถในการแสดงผลของหน้าเว็บนั้นโดยสิ้นเชิง ในทำนองเดียวกัน ระบบประมวลผลข้อความที่สร้างขึ้นเพื่อคาดหวังให้อินพุตทั้งหมดในรูปแบบ ASCII สามารถยุติก่อนเวลาอันควรได้หากได้รับอีโมจิหรือการป้อนอักขระที่ไม่เป็นมาตรฐาน

ที่ร้ายกาจกว่านั้น เวกเตอร์การโจมตีที่แฮ็กเกอร์ชื่นชอบคือSQL injectionซึ่งซ่อนการสืบค้นฐานข้อมูลที่เรียกใช้งานได้ที่เป็นอันตรายภายในช่องป้อนข้อมูลที่ไม่เป็นอันตราย สิ่งนี้ไม่เพียงทำให้แอปพลิเคชันทำงานล้มเหลวเท่านั้น แต่ยังอาจสูญเสียการควบคุมชั้นข้อมูลทั้งหมดอีกด้วย

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

เฟรมเวิร์ก Java ยอดนิยม เช่น Apache BVal และ Hibernate Validator ทำการล้างข้อมูลอินพุตตามคำอธิบายประกอบที่เรียบง่าย และรวมเข้ากับแอปพลิเคชันที่ใช้ Java ได้อย่างง่ายดาย

ตรรกะที่ใช้งานไม่ดี

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

Java มีโครงสร้างในตัวเพื่อจัดการคลาสของข้อผิดพลาดรันไทม์ที่เกี่ยวข้องกับโค้ดทั่วไป ที่เรียกว่า RuntimeException หรือข้อยกเว้นที่ไม่ได้ตรวจสอบ Java 17กำหนดข้อผิดพลาดดังกล่าว 78 ข้อใน SDK เพียงอย่างเดียว และโครงการและเฟรมเวิร์กอื่นๆ ยังกำหนดข้อผิดพลาด RuntimeException ของตนเองเพิ่มเติม

ข้อยกเว้นรันไทม์
ArrayIndexOutOfBoundException
ข้อยกเว้นการปรับเปลี่ยนพร้อมกัน
ClassCastException
…

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

ทรัพยากรรันไทม์ไม่เพียงพอ

นักพัฒนาซอฟต์แวร์ไม่ต้องแบกรับความผิดสำหรับข้อผิดพลาดรันไทม์ทุกประเภทที่เกิดขึ้น ข้อผิดพลาดรันไทม์จำนวนมากใน Java เกี่ยวข้องกับข้อจำกัดด้านทรัพยากรที่เกิดจากปัญหาเกี่ยวกับโครงสร้างพื้นฐาน ตัวอย่าง ได้แก่ การหมดเวลาของเครือข่ายสภาวะหน่วยความจำไม่เพียงพอการใช้งาน CPU มากเกินไปหรือการไม่สามารถกำหนดเวลาเธรดบนโปรเซสเซอร์

วิธีหนึ่งในการหลีกเลี่ยงข้อผิดพลาดรันไทม์ที่เกี่ยวข้องกับทรัพยากรคือการใช้เครื่องมือทดสอบโหลด เช่น JMeter หรือ LoadRunner ในไปป์ไลน์ CI/CD ของแอปพลิเคชัน หากเครื่องมือเหล่านี้ตรวจพบปัญหาด้านประสิทธิภาพที่เป็นไปได้ เครื่องมือเหล่านี้สามารถหยุดแอปพลิเคชันก่อนที่จะย้ายไปยังไปป์ไลน์ไปสู่การปรับใช้จริง

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

ทีม DevOps ต้องตรวจสอบเมตริกประสิทธิภาพด้วยเครื่องมือเพื่อตรวจจับและลดข้อผิดพลาดรันไทม์ที่เกี่ยวข้องกับทรัพยากร ตัวอย่างของเครื่องมือดังกล่าว ได้แก่ JDK Flight Recorder และJava Mission Control

สำหรับแอปพลิเคชันที่มีเวิร์กโหลดที่คาดเดาไม่ได้โดยสิ้นเชิง ให้ใช้เทคโนโลยีโหลดบาลานซ์บนคลาวด์เพื่อจัดสรรทรัพยากรอย่างยืดหยุ่น ซึ่งจะช่วยขจัดทั้งทรัพยากรที่จัดสรรน้อยเกินไป และกับดักการซื้อฮาร์ดแวร์ราคาแพงที่ไม่ค่อยได้ใช้

การกำหนดค่าทรัพยากรภายนอก

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

ทรัพยากรภายนอกอาจทำให้เกิดข้อผิดพลาดรันไทม์ได้ หากเกิดสถานการณ์ใดๆ ต่อไปนี้โดยไม่มีการอัพเดตที่สอดคล้องกับโปรแกรมที่เรียกใช้:

การเปลี่ยนแปลงที่อยู่ IP;
ข้อมูลประจำตัวเปลี่ยน;
การเปลี่ยนแปลงการกำหนดค่าไฟร์วอลล์ หรือ
ระบบภายนอกหยุดทำงานเพื่อการบำรุงรักษา

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

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

ช่องโหว่ของห้องสมุดบุคคลที่สาม

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

น่าเสียดายที่ข้อบกพร่องในไลบรารีของบุคคลที่สามกลายเป็นข้อบกพร่องในแอปพลิเคชันที่คุณปรับใช้ สิ่งนี้กลายเป็นเรื่องจริงที่น่าอึดอัดใจสำหรับโลก Java ในเดือนธันวาคม 2021 เนื่องจากLDAP แทรกข้อบกพร่องในไลบรารี Log4j 2 ที่ใช้กันอย่างแพร่หลายบังคับให้ JVM ทั่วโลกต้องออฟไลน์

วิธีหนึ่งในการบรรเทาความเป็นไปได้ที่การพึ่งพาซอฟต์แวร์ทำให้เกิดข้อผิดพลาดรันไทม์ในแอปพลิเคชันคือการใช้ไลบรารีที่เชื่อถือได้จากองค์กร เช่น Apache หรือ Eclipse เท่านั้น

มาตรการป้องกันอีกประการหนึ่งคือการอัปเดตการพึ่งพาของแอปพลิเคชันเป็นเวอร์ชันล่าสุดเป็นประจำทันทีที่การอัปเดตพร้อมใช้งาน

สุดท้าย ระวังการพึ่งพารองหรือตติยภูมิ — การพึ่งพาหลักของคุณพึ่งพาอาศัย — และระวังความเสี่ยงใด ๆ ที่นำมาด้วย

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

ข้อผิดพลาดรันไทม์ปรากฏขึ้นอย่างไร

ยินดีด้วย! หากพรอมต์คำสั่งของคุณมีลักษณะดังนี้:

จากนั้นคุณก็คอมไพล์โปรแกรมของคุณเป็น Java bytecode ได้สำเร็จ หมายความว่าโค้ดของคุณไม่มีปัญหาทางวากยสัมพันธ์! แต่ตามชื่อไฟล์ที่เราเรียกใช้โปรแกรมนี้:

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

นี่คือส่วนสำคัญของข้อผิดพลาดรันไทม์

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

java.lang.ArrayIndexOutOfBoundsException: 5 : นี่เป็นข้อผิดพลาดที่เกิดขึ้น โดยทั่วไป ชื่อของข้อผิดพลาดจะทำให้คุณทราบสิ่งที่อาจเกิดขึ้น ในกรณีนี้ เรารู้ว่ามันเกี่ยวข้องกับอาร์เรย์และการออกนอกพื้นที่ที่กำหนดสำหรับอาร์เรย์

ที่ RunTimeErrors.main(RunTimeErrors.java:10) : สิ่งนี้เรียกว่าการติดตามสแต็ก ซึ่งจะบอกคุณถึงรายการของวิธีการดำเนินการเมื่อเกิดข้อผิดพลาด

RunTimeErrors.mainบอกเราว่าข้อผิดพลาดนี้เกิดขึ้นภายในเมธอดหลักของคลาส RunTimeErrors
RunTimeErrors.java:10บอกเราว่าไฟล์นี้เกิดขึ้นที่ใดและเกิดขึ้นที่บรรทัดใด ในกรณีนี้ เกิดขึ้นในชั้นเรียนหลักของเราที่บรรทัดที่10

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

ลองใช้NullPointerExceptionเป็นตัวอย่าง:

if(t == null) 
 throw new NullPointerException();

if(t != null) {
  // work with t reference
}

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

//: exceptions/NeverCaught.java 
// Ignoring RuntimeExceptions. 
// {ThrowsException} 
public class NeverCaught { 
 static void f() { 
 throw new RuntimeException("From f()"); 
 } 
 static void g() { 
 f(); 
 } 
 public static void main(String[] args) { 
 g(); 
 } 
} ///:~

Exception in thread "main" Java.lang.RuntimeException: From f() 
    at NeverCaught.f(NeverCaught.Java:7) 
    at NeverCaught.g(NeverCaught.Java:10) 
    at NeverCaught.main(NeverCaught.Java:13)

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

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

ข้อผิดพลาดที่คุณในฐานะโปรแกรมเมอร์ควรตรวจสอบในโค้ดของคุณ (เช่นArraylndexOutOfBoundsExceptionซึ่งคุณควรให้ความสนใจกับขนาดของอาร์เรย์) ข้อยกเว้นที่เกิดขึ้นจากจุดที่ 1 มักจะกลายเป็นปัญหาสำหรับจุด

คุณสามารถดูได้ว่าการมีข้อยกเว้นในกรณีนี้มีประโยชน์มหาศาลเพียงใด เนื่องจากจะช่วยในกระบวนการดีบัก

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

ตัวอย่างข้อผิดพลาดรันไทม์

public class Temp {
public static void main(String[] args) {
  Temp t = initT();
  
  t.foo("Hi");
  
 }
 private static Temp initT() {
  return null;
 }
 public void foo(String s) {
  System.out.println(s.toLowerCase());
 }
}

Exception in thread "main" java.lang.NullPointerException
	at Temp.main(Temp.java:7)

มีกลุ่มประเภทข้อยกเว้นทั้งหมดที่อยู่ในหมวดหมู่นี้ พวกเขาจะถูกส่งโดยอัตโนมัติโดย Java และคุณไม่จำเป็นต้องรวมไว้ในข้อกำหนดข้อยกเว้นของคุณ สะดวกพอ พวกมันทั้งหมดถูกจัดกลุ่มเข้าด้วยกันโดยวางไว้ภายใต้คลาสพื้นฐานเดียวที่เรียกว่าRuntimeExceptionซึ่งเป็นตัวอย่างที่สมบูรณ์แบบของการสืบทอด: มันสร้างตระกูลของประเภทที่มีลักษณะและพฤติกรรมบางอย่างเหมือนกัน นอกจากนี้ คุณไม่จำเป็นต้องเขียนข้อกำหนดข้อยกเว้นโดยระบุว่าเมธอดอาจทิ้ง RuntimeException (หรือประเภทใดก็ตามที่สืบทอดมาจากRuntimeException ) เนื่องจากเป็นข้อยกเว้นที่ไม่ได้ตรวจสอบ เนื่องจากข้อผิดพลาดดังกล่าวบ่งชี้ข้อบกพร่อง คุณมักจะไม่พบRuntimeException— มันจัดการโดยอัตโนมัติ หากคุณถูกบังคับให้ตรวจสอบRuntimeExceptionsรหัสของคุณอาจยุ่งเกินไป แม้ว่าโดยปกติแล้วคุณจะไม่พบRuntimeExceptionsแต่ในแพ็คเกจของคุณเอง คุณอาจเลือกที่จะทิ้งRuntimeExceptionsบาง ส่วน