ทำไมข้อกำหนดข้อยกเว้นไม่ดี?

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

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

1. ตัวระบุข้อยกเว้นใช้ระบบชนิดที่ไม่สอดคล้องกับภาษาที่เหลือ ("ระบบชนิดเงา")
2. หากฟังก์ชั่นของคุณที่มีตัวระบุข้อยกเว้นมีข้อผิดพลาดอื่นใดนอกจากสิ่งที่คุณได้ระบุไว้โปรแกรมจะถูกยกเลิกในรูปแบบที่ไม่ดีและไม่คาดคิด
3. ตัวระบุข้อยกเว้นจะถูกลบออกในมาตรฐาน C ++ ที่กำลังจะมาถึง

ฉันพลาดอะไรบางอย่างที่นี่หรือนี่คือเหตุผลทั้งหมดเหรอ?

ความคิดเห็นของฉัน:

เกี่ยวกับ 1): แล้วอะไรล่ะ C ++ อาจเป็นภาษาการเขียนโปรแกรมที่ไม่สอดคล้องกันมากที่สุดที่เคยมีมา เรามีมาโคร, goto / label, horde (hoard?) ของพฤติกรรมที่ไม่ได้กำหนด - / ไม่ระบุ / / การนำไปใช้งาน, ประเภทจำนวนเต็มที่กำหนดไม่ดี, กฎการส่งเสริมประเภทโดยนัยทั้งหมด, คำหลักกรณีพิเศษเช่นเพื่อน, อัตโนมัติ ลงทะเบียนชัดเจน ... และอื่น ๆ บางคนอาจเขียนหนังสือหนา ๆ หลายเล่มเกี่ยวกับความแปลกประหลาดทั้งหมดใน C / C ++ เหตุใดผู้คนจึงตอบโต้กับความไม่สอดคล้องนี้โดยเฉพาะซึ่งเป็นข้อบกพร่องเล็ก ๆ น้อย ๆ เมื่อเปรียบเทียบกับคุณสมบัติที่เป็นอันตรายอื่น ๆ อีกมากมายของภาษา

เกี่ยวกับ 2): นั่นไม่ใช่ความรับผิดชอบของฉันเองเหรอ? มีวิธีอื่นอีกมากมายที่ฉันสามารถเขียนบั๊กที่ร้ายแรงใน C ++ เหตุใดกรณีนี้จึงเลวร้ายกว่านี้? แทนที่จะเขียนthrow(int)แล้วขว้าง Crash_t ฉันก็อาจอ้างได้ว่าฟังก์ชั่นของฉันคืนตัวชี้ไปที่ int จากนั้นสร้างตัวอักษรที่ชัดเจนชัดเจนและส่งกลับตัวชี้ไปที่ Crash_t จิตวิญญาณของ C / C ++ ได้เสมอที่จะทิ้งความรับผิดชอบส่วนใหญ่ให้กับโปรแกรมเมอร์

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

มาจากโลกของโปรแกรม C แบบฝังตัวที่กำหนดแน่นอนที่สุดแน่นอนฉันอยากรู้ว่าฟังก์ชั่นอะไรจะทำให้ฉัน หากมีบางอย่างในภาษาที่สนับสนุนว่าทำไมไม่ใช้มัน? ทางเลือกที่ดูเหมือนจะเป็น:

void func() throw(Egg_t);

และ

void func(); // This function throws an Egg_t

ฉันคิดว่ามีโอกาสสูงที่ผู้เรียกจะไม่สนใจ / ลืมใช้การลองจับในกรณีที่สองน้อยกว่าในกรณีแรก

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

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

และจากมุมมองของผู้ใช้พวกเขาไม่สามารถดูแลน้อยลงหากพวกเขาได้รับกล่องข้อความที่ชั่วร้ายจากระบบปฏิบัติการว่า "โปรแกรมสิ้นสุดลง Blablabla ตามที่อยู่ 0x12345" หรือกล่องข้อความชั่วร้ายจากโปรแกรมของคุณที่พูดว่า "ข้อยกเว้นจัดการ: myclass func.something" ข้อผิดพลาดยังคงอยู่ที่นั่น

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

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

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

เหตุผลหนึ่งที่ไม่มีใครใช้พวกเขาเป็นเพราะสมมติฐานหลักของคุณผิด:

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

struct foo {};
struct bar {};

struct test
{
    void baz() throw(foo)
    {
        throw bar();
    }
};

int main()
{
    test x;
    try { x.baz(); } catch(bar &b) {}
}

โปรแกรมนี้จะรวบรวมกับข้อผิดพลาดหรือคำเตือนไม่มี

นอกจากนี้แม้ว่าข้อยกเว้นจะได้รับการติดตั้งโปรแกรมยังคงยุติลง

แก้ไข: เพื่อตอบจุดในคำถามของคุณ, catch (... ) (หรือดีกว่า, catch (std :: exeption &) หรือคลาสฐานอื่น ๆแล้ว catch (... ) ยังคงมีประโยชน์แม้ว่าคุณจะไม่ รู้ว่าเกิดอะไรขึ้น

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

การสัมภาษณ์กับ Anders Hejlsbergนี้ค่อนข้างโด่งดัง ในนั้นเขาอธิบายว่าทำไมทีมออกแบบ C # ยกเลิกการตรวจสอบข้อยกเว้นตั้งแต่แรก โดยสรุปมีสองเหตุผลหลักคือความสามารถในการปรับขนาดได้

ฉันรู้ว่า OP กำลังมุ่งเน้นไปที่ C ++ ในขณะที่ Hejlsberg กำลังพูดถึง C # แต่ประเด็นที่ Hejlsberg ทำนั้นใช้ได้กับ C ++ อย่างสมบูรณ์แบบเช่นกัน