เมื่อใดที่ควรมีการยืนยันในรหัสการผลิต [ปิด]

มีการอภิปรายที่เกิดขึ้นที่ comp.lang.c ++ มีการตรวจสอบว่ายืนยันหรือไม่ซึ่งใน C ++ นั้นมีอยู่เฉพาะในการสร้างข้อบกพร่องโดยค่าเริ่มต้นควรเก็บไว้ในรหัสการผลิตหรือไม่

เห็นได้ชัดว่าแต่ละโครงการจะไม่ซ้ำกันดังนั้นคำถามของฉันที่นี่คือไม่มากไม่ว่าจะยืนยันควรจะเก็บไว้, แต่ในกรณีนี้เป็นฝากฝัง / ไม่ได้เป็นความคิดที่ดี

โดยการยืนยันฉันหมายถึง:

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

ฉันไม่จำเป็นต้องพูดถึง C หรือ C ++

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

ความเห็น / ประสบการณ์ของคุณคืออะไร

ไชโย

คาร์ล

ดูคำถามที่เกี่ยวข้องที่นี่

การตอบสนองและการปรับปรุง

เฮ้เกรแฮม

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

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

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

เบี่ยงประเด็นเล็กน้อย แต่เป็นประเด็นสำคัญในการอภิปราย

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

คาร์ล

โทมัส

ใช่ฉันมี Code Complete และต้องบอกว่าฉันไม่เห็นด้วยอย่างยิ่งกับคำแนะนำเฉพาะนั้น

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

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

คาร์ล

การยืนยันเป็นความคิดเห็นที่ไม่ล้าสมัย เอกสารเหล่านี้มีจุดประสงค์ทางทฤษฎีใดและไม่ควรเกิดรัฐใด หากมีการเปลี่ยนแปลงรหัสเพื่ออนุญาตให้มีการเปลี่ยนแปลงสถานะผู้พัฒนาจะได้รับแจ้งในไม่ช้าและจำเป็นต้องอัปเดตการยืนยัน

อนุญาตให้ฉันอ้างอิงรหัสของ Steve McConnell ให้สมบูรณ์ ส่วนเกี่ยวกับการยืนยันคือ 8.2

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

อย่างไรก็ตามภายหลังในส่วนเดียวกันคำแนะนำนี้จะได้รับ:

สำหรับรหัสที่มีประสิทธิภาพสูงให้ยืนยันและจัดการข้อผิดพลาดต่อไป

ฉันคิดว่าตราบใดที่ประสิทธิภาพการทำงานไม่เป็นปัญหาให้ออกจากการยืนยัน แต่แทนที่จะแสดงข้อความให้เขียนลงไฟล์บันทึก ฉันคิดว่าคำแนะนำนั้นอยู่ใน Code Complete แต่ฉันไม่พบมันในตอนนี้

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

ถ้ามันไม่คุ้มค่าในการพิสูจน์ว่ามันมีประสิทธิภาพมากกว่ามันก็ไม่คุ้มค่าที่จะเสียสละความชัดเจนในการเล่นการพนัน "- Steve McConnell 1993

http://c2.com/cgi/wiki?ShipWithAssertionsOn

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

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

คำถามที่น่าสนใจกว่านี้คือในขั้นตอนการทดสอบของคุณคุณปิดการยืนยันเมื่อใด

คำยืนยันไม่ควรอยู่ในรหัสการผลิต หากการยืนยันโดยเฉพาะดูเหมือนว่ามันอาจเป็นประโยชน์ในรหัสการผลิตก็ไม่ควรเป็นการยืนยัน if( condition != expected ) throw exceptionมันควรจะมีการตรวจสอบข้อผิดพลาดเวลาทำงานคือสิ่งที่รหัสเช่นนี้

คำว่า 'ยืนยัน' ได้มาหมายถึง "การตรวจสอบเวลาการพัฒนาเท่านั้นซึ่งจะไม่ถูกดำเนินการบนสนาม"

หากคุณเริ่มคิดว่าการยืนยันอาจนำไปสู่สนามคุณจะต้องเริ่มคิดอย่างเป็นอันตรายเช่นหลีกเลี่ยงไม่ได้ว่าการยืนยันที่ได้รับนั้นคุ้มค่าหรือไม่ ไม่มีการยืนยันซึ่งไม่คุ้มค่าที่จะทำ คุณไม่ควรถามตัวเองว่า "ฉันควรจะยืนยันเรื่องนี้หรือไม่?" คุณควรถามตัวเองว่า "มีอะไรฉันลืมยืนยันบ้างไหม"

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

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

ใน C ++ ของฉันฉันกำหนด REQUIRE (x) ซึ่งเป็นเหมือน assert (x) ยกเว้นว่ามันจะพ่นข้อยกเว้นถ้าการยืนยันนั้นล้มเหลวใน build build

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

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

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

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

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

ซอฟต์แวร์เซิร์ฟเวอร์ฐานข้อมูลของเรามีทั้งการยืนยันและตรวจแก้จุดบกพร่อง การยืนยันการแก้ปัญหาเป็นเพียงแค่นั้น - พวกเขาจะถูกลบออกในรหัสการผลิต การยืนยันการผลิตจะเกิดขึ้นก็ต่อเมื่อ (a) มีเงื่อนไขบางอย่างที่ไม่ควรมีอยู่และ (b) เป็นไปไม่ได้ที่จะกู้คืนจากเงื่อนไขนี้ได้อย่างน่าเชื่อถือ การยืนยันการผลิตบ่งชี้ว่ามีข้อบกพร่องในซอฟต์แวร์หรือเกิดความเสียหายของข้อมูลบางประเภท

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

ต้องบอกว่าเรายังพยายามหลีกเลี่ยงการยืนยันการผลิตในการปฏิบัติงานที่สำคัญ

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

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

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

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

ฟังก์ชั่น readfile นั้นในบริบทนี้และอาจเป็นไปตามข้อกำหนดการออกแบบของมันค่อนข้างจะถือว่าเป็นไปได้ที่จะได้รับไฟล์ PTR ที่ถูกต้อง ดังนั้นมันจะเป็นการสิ้นเปลืองที่จะเพิ่มรหัสการจัดการข้อผิดพลาดสำหรับกรณีลบในโปรแกรมอย่างง่าย อย่างไรก็ตามอย่างน้อยก็ควรมีการบันทึกข้อสมมติฐานอย่างใด - ตรวจสอบให้แน่ใจว่า --- เป็นจริงกรณีนี้ก่อนดำเนินการต่อ ไม่ควรสันนิษฐานว่าจริง ๆ แล้วจะใช้ได้ในกรณีที่เรียกว่าไม่ถูกต้องหรือคัดลอก / วางลงในโปรแกรมอื่นเช่น

ดังนั้น readfile () {ยืนยัน (fptr! = NULL); .. } มีความเหมาะสมในกรณีนี้ในขณะที่การจัดการข้อผิดพลาดเต็มรูปแบบไม่ได้ (ไม่สนใจข้อเท็จจริงที่ว่าการอ่านไฟล์จริง ๆ แล้วจะต้องมีระบบจัดการข้อผิดพลาดอยู่แล้ว)

และใช่การยืนยันเหล่านั้นควรอยู่ในรหัสการผลิตเว้นแต่จะมีความจำเป็นอย่างยิ่งที่จะต้องปิดการใช้งาน แม้ว่าคุณควรปิดการใช้งานเฉพาะในส่วนที่สำคัญต่อประสิทธิภาพ

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

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

สถานการณ์ไม่ได้เป็นการเชิญ ยืนยันการใช้งานแม้ในการผลิต

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

ฉันเสนอตัวอย่าง

file = create-some-file();
_throwExceptionIf( file.exists() == false, "FILE DOES NOT EXIST");

ต่อต้าน

file = create-some-file();
ASSERT(file.exists());

แอปพลิเคชันจะจัดการกับการยืนยันอย่างไร ฉันชอบtry catchวิธีการเดิมในการจัดการกับข้อผิดพลาดร้ายแรง

ส่วนใหญ่เมื่อฉันใช้การยืนยันใน java (คำหลัก assert) ฉันจะเพิ่มรหัสการผลิตบางส่วนโดยอัตโนมัติหลังจาก ตามกรณีอาจเป็นข้อความบันทึกข้อยกเว้น ... หรือไม่มีอะไร

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

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

มีสองสามจุดที่จะหลีกเลี่ยงการเปิดใช้งานการยืนยันในรหัสการผลิต: 1. คุณไม่ต้องการให้ผู้ใช้ปลายทางเห็นข้อความเช่น "ASSERTION ล้มเหลว MyPrivateClass.cpp บรรทัด 147. ผู้ใช้ไม่ใช่วิศวกร QA ของคุณ 2. การรับรองอาจ มีอิทธิพลต่อประสิทธิภาพ

อย่างไรก็ตามมีเหตุผลหนึ่งที่สำคัญในการออกจากการยืนยัน: ASSERTION อาจมีผลต่อประสิทธิภาพและเวลาและบางครั้งเรื่องนี้น่าเศร้า (โดยเฉพาะในระบบฝังตัว)

ฉันมักจะลงคะแนนให้ออกจากการยืนยันในรหัสการผลิต แต่ให้แน่ใจว่าลึกหนาบางพิมพ์ยืนยันเหล่านี้ไม่ได้สัมผัสกับผู้ใช้

~ Yitzik

การยืนยันเป็นข้อผิดพลาดบริสุทธิ์และเรียบง่ายดังนั้นควรจัดการเหมือน

เนื่องจากข้อผิดพลาดควรได้รับการจัดการในโหมดการปล่อยดังนั้นคุณไม่จำเป็นต้องยืนยัน

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