`catch (…) {throw; } `การปฏิบัติที่ไม่ดี?

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

try
{
  // Stuff
}
catch (...)
{
  // Some cleanup
  throw;
}

เป็นที่ยอมรับในกรณีที่ RAII ไม่ได้บังคับ (โปรดอย่าถาม ... ทุกคนใน บริษัท ของฉันชอบการเขียนโปรแกรมเชิงวัตถุและ RAII มักถูกมองว่าเป็น "สิ่งที่ไร้ประโยชน์ต่อโรงเรียน" ... )

เพื่อนร่วมงานของฉันบอกว่าคุณควรรู้อยู่เสมอว่าจะมีข้อยกเว้นอะไรบ้างและคุณสามารถใช้โครงสร้างเช่น:

try
{
  // Stuff
}
catch (exception_type1&)
{
  // Some cleanup
  throw;
}
catch (exception_type2&)
{
  // Some cleanup
  throw;
}
catch (exception_type3&)
{
  // Some cleanup
  throw;
}

มีวิธีปฏิบัติที่ดีที่ยอมรับอย่างดีเกี่ยวกับสถานการณ์เหล่านี้หรือไม่?

เพื่อนร่วมงานของฉันบอกว่าคุณควรรู้อยู่เสมอว่าจะมีข้อยกเว้นอะไร [... ]

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

ว่าในโลกระดับเช่นสามารถstd::vectorแม้กระทั่งแกล้งจะรู้ว่าสิ่งก่อสร้างสำเนาจะโยนขณะที่ยังคงรับประกันความปลอดภัยยกเว้น?

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

สิ่งที่คุณดูเหมือนจะติดอยู่คือนรกที่เฉพาะเจาะจงของคนที่พยายามมีเค้กและกินมันด้วย

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

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

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

สิ่งที่ RAII ให้คุณเกี่ยวกับการจัดการข้อยกเว้นคือการล้างข้อมูลฟรี หากทุกอย่าง RAII ถูกห่อหุ้มอย่างถูกต้องทุกอย่างจะถูกล้างอย่างถูกต้อง คุณไม่จำเป็นต้องมีcatchงบทำความสะอาดอีกต่อไป ในกรณีนี้ไม่มีเหตุผลที่จะเขียนcatch(...)คำสั่ง

ดังนั้นผมจะยอมรับว่าcatch(...)เป็นความชั่วร้ายส่วนใหญ่ ... ชั่วคราว

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

คุณไม่สามารถมีหนึ่งโดยไม่มีอื่น ๆ คุณไม่สามารถพูดได้ว่าทั้ง RAII และ catch(...)ไม่ดี คุณต้องการอย่างน้อยหนึ่งอย่าง มิฉะนั้นคุณจะไม่ได้รับการยกเว้นอย่างปลอดภัย

แน่นอนว่ามีการใช้งานที่ถูกต้อง แต่หายากcatch(...)ที่ไม่ใช่แม้แต่ RAII ที่สามารถขับไล่ได้: รับการexception_ptrส่งต่อไปยังผู้อื่น โดยทั่วไปผ่านpromise/futureอินเทอร์เฟซหรือคล้ายกัน

เพื่อนร่วมงานของฉันบอกว่าคุณควรรู้อยู่เสมอว่าจะมีข้อยกเว้นอะไรบ้างและคุณสามารถใช้โครงสร้างเช่น:

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

กล่าวโดยย่อ: นี่เป็นปัญหาที่ RAII ถูกสร้างขึ้นเพื่อแก้ไข (ไม่ใช่ว่ามันจะไม่แก้ปัญหาอื่น ๆ )

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

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

สองความเห็นจริง ๆ อย่างแรกคือขณะที่อยู่ในโลกในอุดมคติคุณควรรู้เสมอว่ามีข้อยกเว้นอะไรบ้างในทางปฏิบัติหากคุณกำลังจัดการกับห้องสมุดบุคคลที่สามหรือคอมไพล์ด้วยคอมไพเลอร์ของ Microsoft คุณก็ไม่ควรทำ มากขึ้นถึงจุดอย่างไรก็ตาม; แม้ว่าคุณจะทราบข้อยกเว้นที่เป็นไปได้ทั้งหมดนั้นมีความเกี่ยวข้องหรือไม่ catch (...)เป็นการแสดงออกถึงความตั้งใจที่ดีกว่าcatch ( std::exception const& )แม้สมมติว่าข้อยกเว้นที่เป็นไปได้ทั้งหมดมาจาก std::exception(ซึ่งจะเป็นกรณีในโลกอุดมคติ) สำหรับการใช้ catch catch หลายบล็อกหากไม่มีฐานร่วมกันสำหรับข้อยกเว้นทั้งหมดนั่นคือการทำให้งงงวยอย่างจริงจังและฝันร้ายการบำรุงรักษา คุณรู้ได้อย่างไรว่าพฤติกรรมทั้งหมดเหมือนกัน? และนั่นคือเจตนา? และจะเกิดอะไรขึ้นถ้าคุณต้องเปลี่ยนพฤติกรรม (เช่นแก้ไขข้อผิดพลาด)? มันง่ายเกินไปที่จะพลาดไป

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

หมายความว่า:

try
{
  // Stuff
}
catch (...)
{
  // General stuff
}

ไม่ดีเพราะมันจะซ่อนความผิดพลาดอย่างเงียบๆ

อย่างไรก็ตาม:

try
{
  // Stuff
}
catch (exception_type_we_can_handle&)
{
  // Deal with the known exception
}

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

ในทำนองเดียวกัน:

try
{
  // Stuff
}
catch (...)
{
  // Rollback transactions, log errors, etc
  throw;
}

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

คำตอบใด ๆ เกี่ยวกับใช่หรือไม่ใช่ควรมีเหตุผลว่าทำไมจึงเป็นเช่นนี้

การพูดว่ามันผิดเพราะฉันได้รับการสอนในลักษณะที่เป็นเพียงความคลั่งไคล้ตาบอด

การเขียน//Some cleanup; throwหลาย ๆ ครั้งเหมือนในตัวอย่างของคุณผิดเพราะการทำสำเนารหัสและนั่นคือภาระการบำรุงรักษา การเขียนเพียงครั้งเดียวจะดีกว่า

การเขียนcatch(...)ข้อยกเว้นทั้งหมดเป็นความผิดเพราะคุณควรจัดการข้อยกเว้นที่คุณรู้จักวิธีการจัดการเท่านั้นและด้วยสัญลักษณ์แทนนั้นคุณสามารถกำหนดได้มากกว่าที่คุณคาดหวัง

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

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

void DoSomethingImportant()
{
    try
    {
        Log("Going to do something important");
        DoIt();
    }
    catch (std::exception &e)
    {
        Log("Error doing something important: %s", e.what());
        throw;
    }
    catch (...)
    {
        Log("Unexpected error doing something important");
        throw;
    }
    Log("Success doing something important");
}

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

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

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