1. ภาพรวม
มีคีย์ยืนยันในภาษา C และ C++ ซึ่งหมายถึงการยืนยัน
ใน Java ยังมีคีย์เวิร์ด assert ซึ่งหมายถึงการยืนยัน การใช้งานและความหมายคล้ายกัน
2. ไวยากรณ์
ใน Java คีย์เวิร์ด assert ได้รับการแนะนำจาก JAVA SE 1.4 เพื่อหลีกเลี่ยงข้อผิดพลาดที่เกิดจากการใช้คีย์เวิร์ด assert ในโค้ด Java เวอร์ชันเก่า Java จะไม่เปิดใช้งานการตรวจสอบการยืนยันตามค่าเริ่มต้นเมื่อดำเนินการ (ในขณะนี้ คำสั่ง Assertion ทั้งหมดจะ ถูกละเว้น!) หากคุณต้องการเปิดใช้งานการตรวจสอบการยืนยัน คุณต้องเปิดใช้งานโดยใช้สวิตช์ -enableassertions หรือ -ea
ไวยากรณ์คีย์เวิร์ด assert นั้นง่ายมาก และมีประโยชน์สองประการ:
1. ยืนยัน <นิพจน์บูลีน>
ถ้า <boolean expression> เป็นจริง การทำงานของโปรแกรมจะดำเนินต่อไป
หากเป็นเท็จ โปรแกรมจะส่ง AssertionError และยุติการดำเนินการ
2. ยืนยัน <นิพจน์บูลีน>: <นิพจน์ข้อความแสดงข้อผิดพลาด>
ถ้า <boolean expression> เป็นจริง การทำงานของโปรแกรมจะดำเนินต่อไป
หากเป็นเท็จ โปรแกรมจะส่ง java.lang.AssertionError และเข้าสู่ <error message expression>
3. ตัวอย่างการใช้งาน
ตัวอย่างได้รับด้านล่างเพื่อแสดงการใช้งาน:
คัดลอกรหัสรหัส ดังต่อไปนี้:
AssertFoo คลาสสาธารณะ {
โมฆะคงสาธารณะ main (String args []) {
//ผลลัพธ์ของการยืนยันข้อ 1 เป็นจริง จากนั้นจึงดำเนินการต่อไป
ยืนยันความจริง;
System.out.println("ไม่มีปัญหากับการยืนยัน 1, ไป!");
System.out.println("/n-----------------/n");
//ผลลัพธ์ของการยืนยันข้อ 2 เป็นเท็จ และโปรแกรมยุติการทำงาน
assert false : "การยืนยันล้มเหลว ข้อมูลของนิพจน์นี้จะถูกส่งออกเมื่อมีการส่งข้อยกเว้น!";
System.out.println("ไม่มีปัญหากับการยืนยัน 2, ไป!");
-
-
บันทึกโค้ดไปที่ C:/AssertFoo.java จากนั้นดำเนินการดังต่อไปนี้และดูเอาต์พุตคอนโซล:
1. คอมไพล์โปรแกรม:
C:/>javac AssertFoo.java
2. โปรแกรมถูกดำเนินการตามค่าเริ่มต้นโดยไม่ต้องเปิดสวิตช์ -ea:
C:/>java AssertFoo
การยืนยันที่ 1 ไม่เป็นไร ไปกันเลย!
-
การยืนยันที่ 2 ไม่มีปัญหา ไปได้เลย!
3. เปิดสวิตช์ -ea และรันโปรแกรม:
C:/>java -ea AssertFoo
การยืนยันที่ 1 ไม่เป็นไร ไปกันเลย!
-
ข้อยกเว้นในเธรด "main" java.lang.AssertionError: การยืนยันล้มเหลว ข้อมูลของนิพจน์นี้จะ
จะถูกส่งออกเมื่อมีการส่งข้อยกเว้น!
ที่ AssertFoo.main(AssertFoo.java:10)
4. กับดัก
คีย์เวิร์ด assert นั้นใช้งานง่าย แต่การใช้ assert มักจะทำให้คุณตกหลุมพรางที่ลึกลงไปเรื่อยๆ ควรหลีกเลี่ยง. หลังจากการวิจัย ผู้เขียนสรุปเหตุผลดังต่อไปนี้:
1. คำสำคัญยืนยันจะต้องเปิดใช้งานอย่างชัดเจนในขณะรันไทม์จึงจะมีผล มิฉะนั้นการยืนยันของคุณจะไม่มีความหมาย ในปัจจุบัน เครื่องมือ Java IDE หลักไม่ได้เปิดใช้งานฟังก์ชันการตรวจสอบการยืนยัน -ea ตามค่าเริ่มต้น ซึ่งหมายความว่าหากคุณใช้เครื่องมือ IDE ในการเขียนโค้ด คุณจะประสบปัญหาในการดีบักและรัน นอกจากนี้ สำหรับแอปพลิเคชันเว็บ Java โค้ดโปรแกรมจะถูกปรับใช้ในคอนเทนเนอร์ และคุณไม่สามารถควบคุมการทำงานของโปรแกรมได้โดยตรง หากคุณต้องเปิดสวิตช์ -ea คุณจะต้องเปลี่ยนพารามิเตอร์การกำหนดค่าที่ทำงานอยู่ของคอนเทนเนอร์ของเว็บ สิ่งนี้ทำให้เกิดความไม่สะดวกอย่างมากต่อการปลูกถ่ายและการปรับใช้โปรแกรม
2. การใช้ assert แทน if เป็นกับดักที่สอง การตัดสิน assert นั้นคล้ายคลึงกับคำสั่ง if แต่ฟังก์ชันของทั้งสองนั้นแตกต่างกันโดยพื้นฐาน: คีย์เวิร์ด assert มีวัตถุประสงค์เพื่อใช้เมื่อทดสอบและดีบักโปรแกรม แต่ถ้าคุณใช้ assert โดยไม่ตั้งใจเพื่อควบคุมกระบวนการทางธุรกิจของ โปรแกรมจะไม่ถูกใช้ในระหว่างการทดสอบและการดีบัก การลบคีย์เวิร์ด assert หลังจากเสร็จสิ้นหมายถึงการแก้ไขตรรกะปกติของโปรแกรม
3. หากการยืนยันการยืนยันล้มเหลว โปรแกรมจะออกจากการทำงาน สิ่งนี้จะไม่มีวันได้รับการยอมรับในสภาพแวดล้อมการผลิต โดยทั่วไปข้อผิดพลาดที่อาจเกิดขึ้นในโปรแกรมจะได้รับการแก้ไขผ่านการจัดการข้อยกเว้น แต่การใช้การยืนยันนั้นอันตรายมาก เมื่อล้มเหลว ระบบจะหยุดทำงาน
5. ความคิดในการยืนยัน
เนื่องจาก assert มีไว้สำหรับการดีบักโปรแกรมทดสอบและไม่ได้ใช้ในสภาพแวดล้อมการผลิตอย่างเป็นทางการ คุณควรพิจารณาการทดสอบ JUint ที่ดีกว่าเพื่อแทนที่ฟังก์ชัน JUint มีฟังก์ชันหลักมากกว่า assert แน่นอนว่าการดีบักและการทดสอบสามารถทำได้ผ่านการดีบัก IDE จากมุมมองนี้ อนาคตของการยืนยันนั้นเยือกเย็น
ดังนั้น คุณควรหลีกเลี่ยงการใช้คีย์เวิร์ด assert ใน Java เว้นแต่ว่าวันหนึ่ง Java รองรับสวิตช์ -ea เป็นค่าเริ่มต้น คุณก็สามารถพิจารณาได้ เปรียบเทียบว่าการยืนยันจะได้รับประโยชน์มากน้อยเพียงใด นี่คือหลักการให้เราเลือกว่าจะใช้หรือไม่
================================================== ==========
ความคิดเห็น:
ในทางกลับกัน ในองค์ประกอบโอเพ่นซอร์สบางอย่าง เช่น เครื่องมือตรวจสอบและ Junit กระบวนการตัดสินดูเหมือนว่าจะใช้รูปแบบการยืนยัน มีความเป็นไปได้มากว่ามีการใช้การยืนยันจำนวนมาก แต่ผู้เขียนไม่สามารถแน่ใจได้ก่อนที่จะดู ซอร์สโค้ด
หากเป็นการทดสอบง่ายๆ ในระหว่างขั้นตอนการพัฒนา junit ก็เป็นเครื่องมือที่สะดวกและทรงพลัง ไม่มีเหตุผลใดที่จะไม่ใช้มันเมื่อเขียนการยืนยันของคุณเอง
================================================== ==========
ความคิดเห็น:
ขั้นแรกสามารถใช้ในโค้ดทดสอบหน่วยได้ Junit เป็นการรบกวนอย่างมาก หากโค้ดจำนวนมากในโปรเจ็กต์ทั้งหมดใช้ Junit ก็จะเป็นการยากที่จะลบออกหรือเลือกเฟรมเวิร์กอื่น หากมีโค้ดการทดสอบหน่วยจำนวนมาก และคุณต้องการใช้กรณีการทดสอบหน่วยเหล่านี้ซ้ำ คุณควรเลือก assert แทน Junit เพื่ออำนวยความสะดวกในการใช้เฟรมเวิร์กการทดสอบหน่วยอื่นๆ เช่น TestNG ด้วยเหตุผลเดียวกัน Junit ไม่ควรปรากฏในโค้ดการทำงานอย่างเป็นทางการเลย และควรใช้ assert
assert ส่วนใหญ่เหมาะสำหรับคลาสพื้นฐาน คลาสเฟรมเวิร์ก คลาสอินเทอร์เฟซ คลาสโค้ดคอร์ และคลาสเครื่องมือ กล่าวอีกนัยหนึ่ง จำเป็นต้องใช้เมื่อผู้เรียกรหัสของคุณเป็นรหัสธุรกิจที่เขียนโดยโปรแกรมเมอร์รายอื่นหรือระบบย่อยอื่น ตัวอย่างเช่น หากคุณสร้างอัลกอริธึมการเรียงลำดับแบบด่วน
คัดลอกรหัสรหัส ดังต่อไปนี้:
รายการคงที่สาธารณะ <int> QuickSort (รายการ <int> รายการ) {
ยืนยันรายการ != null;
//ขอพื้นที่ชั่วคราว
//เริ่มเรียงลำดับ
สำหรับ (int i : รายการ) {
-
-
-
ในกรณีนี้ หากไม่ได้ตรวจสอบความถูกต้องของพารามิเตอร์ขาเข้า ข้อผิดพลาดของตัวชี้ null ที่อธิบายไม่ได้จะถูกส่งออกไป ผู้โทรของคุณอาจไม่ทราบรายละเอียดของรหัสของคุณ และการดีบักข้อผิดพลาดของตัวชี้ null ที่อยู่ลึกลงไปในระบบถือเป็นการเสียเวลา คุณควรแจ้งผู้โทรของคุณโดยตรงและชัดเจนว่ามีปัญหากับพารามิเตอร์ที่ส่งเข้ามา มิฉะนั้นเขาจะสงสัยว่ารหัสของคุณมี BUG การใช้ assert สามารถป้องกันไม่ให้โปรแกรมเมอร์สองคนกล่าวโทษกันและกันเกี่ยวกับปัญหาโค้ดที่พวกเขาเขียน
assert ใช้กับข้อผิดพลาดที่คุณทราบแน่ชัดว่าข้อผิดพลาดคืออะไร และคุณและผู้โทรได้ตกลงกันว่าผู้โทรของคุณควรกำจัดหรือตรวจสอบข้อผิดพลาด คุณบอกผู้โทรของคุณผ่านการยืนยัน assert ใช้ไม่ได้กับข้อผิดพลาดที่เกิดจากระบบภายนอก เช่น ข้อผิดพลาดในข้อมูลที่ผู้ใช้ป้อน หรือข้อผิดพลาดด้านรูปแบบในไฟล์ภายนอก ข้อผิดพลาดเหล่านี้ไม่ได้เกิดจากผู้โทรของคุณ แต่เกิดจากผู้ใช้ และไม่ใช่ข้อยกเว้นด้วยซ้ำ เนื่องจากข้อผิดพลาดในการป้อนข้อมูลและข้อผิดพลาดเกี่ยวกับรูปแบบไฟล์เป็นเรื่องปกติ และข้อผิดพลาดเหล่านี้ควรได้รับการตรวจสอบโดยรหัสธุรกิจ
assert เหมาะกว่าสำหรับคลาสพื้นฐาน, โค้ดเฟรมเวิร์ก, คลาสเครื่องมือ, โค้ดหลัก และโค้ดอินเทอร์เฟซที่ถูกเรียกบ่อยครั้งมากกว่า นี่คือสาเหตุว่าทำไมจึงถูกลบออกเมื่อรันไทม์ รหัสทดสอบควรเปิดใช้งานพารามิเตอร์ -ea ในระหว่างขั้นตอนการทดสอบ เพื่ออำนวยความสะดวกในการทดสอบโค้ดหลักที่อยู่ลึกลงไปในระบบอย่างระมัดระวัง
สาเหตุที่ Java ใช้ assert น้อยลงก็คือ Java มีระบบ OO ที่สมบูรณ์มากและการแปลงประเภทที่บังคับเกิดขึ้นน้อยกว่า ดังนั้นจึงไม่จำเป็นต้องตรวจสอบบ่อยครั้งว่าประเภทของตัวชี้นั้นถูกต้องหรือไม่ และตัวชี้นั้นว่างเปล่าเหมือน C หรือไม่ ในเวลาเดียวกัน Java ไม่ค่อยจัดการหน่วยความจำหรือบัฟเฟอร์โดยตรง ดังนั้นจึงไม่จำเป็นต้องตรวจสอบบ่อยครั้งว่าบัฟเฟอร์ขาเข้าว่างเปล่าหรือข้ามขอบเขตหรือไม่
แต่การใช้ assert well สามารถช่วยปรับปรุงความถูกต้องของโค้ดเฟรมเวิร์ก และลดเวลาการดีบักของผู้ใช้โค้ดเฟรมเวิร์กได้
================================================== =============
ความคิดเห็น:
วัตถุประสงค์ของการยืนยันคือการอนุญาตให้โปรแกรมเมอร์ค้นพบข้อผิดพลาดทางลอจิกของตนเองได้อย่างง่ายดาย โดยไม่ส่งผลกระทบต่อประสิทธิภาพของโปรแกรม ข้อผิดพลาดที่พบโดยการยืนยันไม่ควรเกิดขึ้นเลยและไม่สามารถแทนที่ด้วยข้อยกเว้นได้ ระบบอนุญาตข้อยกเว้นหรือเป็น "ข้อผิดพลาด" ที่ระบบไม่สามารถควบคุมได้ ไม่ใช่ปัญหาเชิงตรรกะของโปรแกรมเมอร์
ควรเปิด assert ในระหว่างการพัฒนาและปิดหลังจากรีลีส