ฉันควรใช้ตัวระบุข้อยกเว้นใน C ++ หรือไม่

ใน C ++ คุณสามารถระบุว่าฟังก์ชันอาจมีหรือไม่มีข้อยกเว้นโดยใช้ตัวระบุข้อยกเว้น ตัวอย่างเช่น:

void foo() throw(); // guaranteed not to throw an exception
void bar() throw(int); // may throw an exception of type int
void baz() throw(...); // may throw an exception of some unspecified type

ฉันสงสัยเกี่ยวกับการใช้งานจริงเนื่องจากสิ่งต่อไปนี้:

1. คอมไพเลอร์ไม่ได้บังคับใช้ตัวระบุข้อยกเว้นอย่างเข้มงวด แต่อย่างใดดังนั้นประโยชน์จึงไม่มาก ตามหลักการแล้วคุณต้องการรับข้อผิดพลาดในการคอมไพล์
2. หากฟังก์ชันละเมิดตัวระบุข้อยกเว้นฉันคิดว่าพฤติกรรมมาตรฐานคือการยุติโปรแกรม
3. ใน VS.Net ถือว่าการโยน (X) เป็นการโยน (... ) ดังนั้นการยึดมั่นในมาตรฐานจึงไม่แข็งแรง

คุณคิดว่าควรใช้ตัวระบุข้อยกเว้นหรือไม่?
โปรดตอบด้วย "ใช่" หรือ "ไม่" และระบุเหตุผลบางประการเพื่อให้เหตุผลสำหรับคำตอบของคุณ

เลขที่

นี่คือตัวอย่างหลายประการว่าทำไม:

1. โค้ดเทมเพลตไม่สามารถเขียนด้วยข้อกำหนดข้อยกเว้น

   template<class T>
   void f( T k )
   {
        T x( k );
        x.x();
   }
   

   สำเนาอาจโยนการส่งผ่านพารามิเตอร์อาจโยนและx()อาจทำให้เกิดข้อยกเว้นที่ไม่รู้จัก

2. ข้อกำหนดข้อยกเว้นมักจะห้ามไม่ให้มีการขยาย

   virtual void open() throw( FileNotFound );

   อาจพัฒนาเป็น

   virtual void open() throw( FileNotFound, SocketNotReady, InterprocessObjectNotImplemented, HardwareUnresponsive );

   คุณสามารถเขียนเป็น

   throw( ... )

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

3. รหัสเดิม

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

   int lib_f();
   
   void g() throw( k_too_small_exception )
   { 
      int k = lib_f();
      if( k < 0 ) throw k_too_small_exception();
   }
   

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

4. เขียนโค้ดที่ส่งคืนข้อผิดพลาดทั่วไปและพ่นในโอกาสพิเศษ

   Error e = open( "bla.txt" );
   if( e == FileNotFound )
       MessageUser( "File bla.txt not found" );
   if( e == AccessDenied )
       MessageUser( "Failed to open bla.txt, because we don't have read rights ..." );
   if( e != Success )
       MessageUser( "Failed due to some other error, error code = " + itoa( e ) );
   
   try
   {
      std::vector<TObj> k( 1000 );
      // ...
   }
   catch( const bad_alloc& b )
   { 
      MessageUser( "out of memory, exiting process" );
      throw;
   }
   

อย่างไรก็ตามเมื่อห้องสมุดของคุณมีข้อยกเว้นของคุณเองคุณสามารถใช้ข้อกำหนดข้อยกเว้นเพื่อระบุเจตนาของคุณได้

หลีกเลี่ยงข้อกำหนดข้อยกเว้นใน C ++ เหตุผลที่คุณให้ไว้ในคำถามของคุณเป็นการเริ่มต้นที่ดีว่าทำไม

ดูสมุนไพรซัทเทอ"มองในทางปฏิบัติที่ยกเว้นข้อมูลจำเพาะ"

ฉันคิดว่าตัว
ระบุข้อยกเว้นมาตรฐาน (สำหรับ C ++) เป็นการทดลองในมาตรฐาน C ++ ซึ่งส่วนใหญ่ล้มเหลว
ข้อยกเว้นคือไม่มีตัวระบุการโยนจะมีประโยชน์ แต่คุณควรเพิ่มบล็อก try catch ที่เหมาะสมภายในเพื่อให้แน่ใจว่ารหัสตรงกับตัวระบุ เฮิร์บซัทเทอร์มีหน้าเรื่อง ก๊อต 82

นอกจากนี้ฉันคิดว่ามันคุ้มค่าที่จะอธิบายการรับประกันข้อยกเว้น

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

การรับประกันข้อยกเว้น

ไม่รับประกัน:

ไม่มีการรับประกันเกี่ยวกับสถานะของอ็อบเจ็กต์หลังจากที่มีการยกเว้น
หลีกเลี่ยงเมธอดในสถานการณ์เหล่านี้อ็อบเจ็กต์ไม่ควรใช้อีกต่อไป

การรับประกันขั้นพื้นฐาน:

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

การรับประกันที่แข็งแกร่ง: (aka Transactional Guarantee)

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

ไม่รับประกันการโยน:

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

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

ตัวระบุข้อยกเว้นที่มีประโยชน์เพียงอย่างเดียวคือ "throw ()" เช่นเดียวกับ "ไม่โยน"

ข้อกำหนดข้อยกเว้นไม่ใช่เครื่องมือที่มีประโยชน์อย่างยิ่งใน C ++ อย่างไรก็ตามมี / มี / การใช้งานที่ดีสำหรับพวกเขาหากรวมกับ std :: ไม่คาดคิด

สิ่งที่ฉันทำในบางโปรเจ็กต์คือโค้ดที่มีข้อกำหนดข้อยกเว้นจากนั้นเรียกใช้ set_un ไม่คาดคิด () ด้วยฟังก์ชันที่จะทำให้เกิดข้อยกเว้นพิเศษสำหรับการออกแบบของฉันเอง ข้อยกเว้นนี้ในการสร้างจะได้รับ backtrace (ในลักษณะเฉพาะแพลตฟอร์ม) และได้มาจาก std :: bad_exception (เพื่อให้สามารถเผยแพร่ได้หากต้องการ) ถ้ามันทำให้เกิดการเรียก terminate () ตามปกติ backtrace จะถูกพิมพ์โดย what () (เช่นเดียวกับข้อยกเว้นดั้งเดิมที่ทำให้เกิด; ไม่ยากที่จะค้นหา) ดังนั้นฉันจึงได้รับข้อมูลว่าสัญญาของฉันอยู่ที่ไหน ละเมิดเช่นข้อยกเว้นของห้องสมุดที่ไม่คาดคิดเกิดขึ้น

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

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

มิฉะนั้นฉันจะไม่พบว่ามีประโยชน์อย่างยิ่งที่จะใช้อะไร แต่throw()เพื่อระบุว่าไม่มีข้อยกเว้นใด ๆ

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

นอกจากนี้ฉันเชื่อว่าการใช้งานได้เลิกใช้แล้วในร่างมาตรฐาน C ++ 0x ปัจจุบัน

ข้อกำหนด "throw ()" ช่วยให้คอมไพลเลอร์ดำเนินการเพิ่มประสิทธิภาพบางอย่างเมื่อทำการวิเคราะห์การไหลของโค้ดหากทราบว่าฟังก์ชันนั้นจะไม่มีข้อยกเว้น (หรืออย่างน้อยก็สัญญาว่าจะไม่มีข้อยกเว้น) Larry Osterman พูดถึงเรื่องนี้สั้น ๆ ที่นี่:

http://blogs.msdn.com/larryosterman/archive/2006/03/22/558390.aspx

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

ใช่ลักษณะการทำงานที่คาดไว้ของข้อยกเว้นที่ไม่ได้ระบุซึ่งถูกโยนออกจากฟังก์ชันที่มีตัวระบุข้อยกเว้นคือการเรียกใช้ terminate ()

ฉันจะสังเกตด้วยว่า Scott Meyers กล่าวถึงเรื่องนี้ใน C ++ ที่มีประสิทธิภาพมากขึ้น C ++ ที่มีประสิทธิภาพและ C ++ ที่มีประสิทธิภาพของเขาเป็นหนังสือที่แนะนำเป็นอย่างยิ่ง

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

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

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

จากบทความ:

http://www.boost.org/community/exception_safety.html

“ เป็นที่ทราบกันดีว่าเป็นไปไม่ได้ที่จะเขียนคอนเทนเนอร์ทั่วไปที่ปลอดภัยเป็นพิเศษ” คำกล่าวอ้างนี้มักจะได้ยินโดยอ้างอิงถึงบทความของ Tom Cargill [4] ซึ่งเขาได้สำรวจปัญหาเรื่องความปลอดภัยที่เป็นข้อยกเว้นสำหรับเทมเพลตสแต็กทั่วไป ในบทความของเขาคาร์กิลล์ตั้งคำถามที่เป็นประโยชน์มากมาย แต่น่าเสียดายที่ไม่สามารถนำเสนอวิธีแก้ปัญหาของเขาได้ 1 เขาสรุปด้วยการแนะนำว่าวิธีแก้ปัญหาอาจเป็นไปไม่ได้ น่าเสียดายที่หลายคนอ่านบทความของเขาว่าเป็น "หลักฐาน" ของการคาดเดานั้น เนื่องจากมีการเผยแพร่จึงมีตัวอย่างของส่วนประกอบทั่วไปที่ปลอดภัยเป็นพิเศษมากมายรวมถึงคอนเทนเนอร์ไลบรารีมาตรฐาน C ++

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

ข้อกำหนดข้อยกเว้น = ขยะโปรดสอบถามนักพัฒนา Java ที่อายุเกิน 30 ปี