การใช้ NotImplementedException


15

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


6
อะไรคือข้อเสียของการใช้ข้อยกเว้นดังกล่าวกับคุณ
SRKX

@SRKX มีความเสี่ยงที่จะมีข้อยกเว้นในการใช้รหัสการผลิตและทำให้การบล็อกรหัสทั้งหมดไม่ทำงาน (ยังไม่ได้เกิดขึ้นกับฉัน แต่เราทุกคนมีวันหยุด) ฉันใช้พวกเขาเป็นการส่วนตัวฉันเป็นห่วงฉันอาจจะมองข้ามข้อเสียบางอย่าง
Tom Squires

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

1
@ DavidThornley คำถามถูกติดแท็กเป็น C # เดิมดังนั้นฉันจึงอ่านแท็ก
svick

@svick: คิดว่าน่าจะเป็น C # ขอบคุณที่เพิ่มแท็ก
David Thornley

คำตอบ:


34

ฉันเชื่อว่าNotImplementedExceptionเป็นวิธีปฏิบัติที่ดีจริง ๆ

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

ฉันอยากจะแนะนำให้ใช้การNotImplementedException รวมกับความคิดเห็นของสิ่งที่ต้องทำวิธีที่คุณรวมความช่วยเหลือ GUI (กับงานใน VS) และความปลอดภัยของโปรแกรม

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


6
ถ้าคุณใช้ Resharper มันจะแสดงNotImplementedExceptions ในลักษณะเดียวกับความคิดเห็นของสิ่งที่ต้องทำ ฉันคิดว่านั่นเป็นคุณสมบัติที่ดี
svick

1
โยนในการฝึกฝน TDD ที่ดีและคุณจะได้ผู้ชนะ
LRE

7

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

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


ราวกับว่าคุณต้องการพฤติกรรมที่แตกต่างใน Debug and Release และการยืนยันจะไม่ตัดออกไป ฉันเชื่อว่า. Net Code Contracts สามารถปิดได้ใน Release
งาน

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

3

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

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


1

ฉันคิดว่ามันเป็นวิธีปฏิบัติที่ดี ทางเลือกกำลังแพร่กระจายค่าหรือสถานะที่ไม่ถูกต้องซึ่งจะส่งผลต่อทั้งรหัสทดสอบและรหัสการผลิต


1
หยุด .... คุณหมายถึงว่าคุณทำงานที่ไหนรหัสที่ใช้ NotImpl จะทำให้ทุกอย่างไปสู่ ​​QA? แม้แต่ในการผลิต?
Steven Evers

3
ไม่ตรงข้าม: NotImpl เป็นเงื่อนไขธง / ข้อผิดพลาดสีแดงขนาดใหญ่ที่ดี แต่สิ่งที่ต้องทำไม่มีค่าความหมายและสามารถทำให้มันเป็นแบบทดสอบหรือการผลิต (ฉันสามารถจินตนาการถึงนโยบายในการกำจัดสิ่งที่ต้องทำจากการผลิต แต่เราไม่มีกฎดังกล่าว)
Larry OBrien

1

ฉันมักจะใช้NotImplementedException- นั่นคือสิ่งที่มันมีไว้เพื่อหลังจากทั้งหมด

สิ่งนี้เกี่ยวข้องกับแนวคิดของ "fail fast": หากโค้ดของคุณมีข้อผิดพลาดเกิดขึ้นซึ่งควรจะถูกดักจับก่อนที่จะทำการผลิต ถ้ามันไม่ได้รับการผลิตแล้วอย่างน้อยลูกค้ารู้ว่าการชุมนุมไม่ถูกต้อง

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


0

โครงการนี้เป็นโครงการอะไร ที่ทำงานหรือที่บ้าน? ที่บ้านทำในสิ่งที่คุณต้องการ - สิ่งที่เตือนคุณได้ดีที่สุดว่าคุณต้องทำทุกอย่างให้เสร็จ

ที่ทำงานให้เขียนเสร็จ

ฉันไม่เห็นสถานการณ์ที่ฉันจะตรวจสอบรหัสที่สามารถ / จะทำลาย devs อื่น ๆ , QA หรืองานสร้าง


ทั้งคู่ฉันพยายามทำตามแนวทางปฏิบัติที่ดีที่บ้านเช่นกัน
Tom Squires

0

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.