ทำไมฉันไม่ควรห่อทุกบล็อคใน“ ลอง” -“ จับ”?

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

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

วิธีการควรจับยกเว้นเมื่อมันสามารถจัดการได้ในทางที่เหมาะสม

มิฉะนั้นให้ส่งผ่านขึ้นโดยหวังว่าวิธีการที่สูงขึ้นของ call stack จะทำให้เกิดความรู้สึกของมัน

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

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

มีบางรหัสที่เกี่ยวข้องกับกลิ่นที่คุณต้องการหลีกเลี่ยงนอกเหนือจากกลิ่น"จับทุกอย่างทุกที่"

1. "catch, log, rethrow" : หากคุณต้องการการบันทึกตามขอบเขตที่กำหนดไว้ให้เขียนคลาสที่ส่งคำสั่ง log ใน destructor เมื่อสแต็กไม่ได้เปิดเนื่องจากข้อยกเว้น (ala std::uncaught_exception()) สิ่งที่คุณต้องทำคือการประกาศอินสแตนซ์การบันทึกในขอบเขตที่คุณสนใจและใน voila คุณมีการบันทึกและไม่มีตรรกะtry/ ไม่จำเป็นcatch

2. "catch, throw translation" : โดยปกติจะชี้ไปที่ปัญหาที่เป็นนามธรรม ถ้าคุณมีการดำเนินการแก้ปัญหาแบบ federated ที่คุณกำลังจะแปลเฉพาะข้อยกเว้นเป็นหนึ่งในหลายทั่วไปมากขึ้นหนึ่งคุณอาจจะมีชั้นที่ไม่จำเป็นของนามธรรม ... และไม่ได้บอกว่า "ฉันอาจจะจำเป็นต้องใช้มันในวันพรุ่งนี้"

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

ฉันพิจารณาโค้ดที่เกลื่อนไปด้วยtry/ catchบล็อกเพื่อให้เป็นเป้าหมายที่ดีสำหรับการตรวจสอบโค้ดและการปรับโครงสร้างใหม่ มันบ่งชี้ว่าการจัดการข้อยกเว้นอย่างใดอย่างหนึ่งไม่เป็นที่เข้าใจดีหรือรหัสกลายเป็นamœbaและอยู่ในความต้องการอย่างจริงจังในการปรับโครงสร้างใหม่

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

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

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

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

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

int ret = SaveFirstSection();

if (ret == FAILED)
{
    /* some diagnostic */
    return;
}

ret = SaveSecondSection();

if (ret == FAILED)
{
    /* some diagnostic */
    return;
}

ret = SaveThirdSection();

if (ret == FAILED)
{
    /* some diagnostic */
    return;
}

นี่คือวิธีที่อาจเขียนด้วยข้อยกเว้น:

// these throw if failed, caught in SaveDocument's catch
SaveFirstSection();
SaveSecondSection();
SaveThirdSection();

ตอนนี้มันชัดเจนมากขึ้นว่าเกิดอะไรขึ้น

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

สมุนไพร Sutter เขียนเกี่ยวกับปัญหานี้ที่นี่ เพื่อการอ่านที่คุ้มค่าแน่นอน
ทีเซอร์:

"การเขียนรหัสที่ปลอดภัยเป็นพิเศษคือการเขียน 'ลอง' และ 'จับ' ในตำแหน่งที่ถูกต้อง" สนทนา

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

ที่จริงแล้วปรากฎว่าความปลอดภัยยกเว้นนั้นไม่ค่อยเกี่ยวกับการเขียน 'ลอง' และ 'จับ' - และยิ่งดีกว่า นอกจากนี้อย่าลืมว่าข้อยกเว้นด้านความปลอดภัยส่งผลกระทบต่อการออกแบบของโค้ด มันไม่ได้เป็นเพียงแค่ความคิดในภายหลังที่สามารถดัดแปลงเพิ่มเติมด้วยการจับพิเศษบางอย่างราวกับว่าปรุงรส

ตามที่ระบุไว้ในคำตอบอื่น ๆ คุณควรตรวจสอบข้อยกเว้นหากคุณสามารถจัดการข้อผิดพลาดที่เหมาะสมได้

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

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

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

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

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

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

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

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

ตัวอย่างเช่นเขาบอกเราว่าหากโปรแกรมพบปัญหาร้ายแรงบางอย่างในสถานที่ที่ไม่สามารถทำสิ่งต่อไปนี้ได้:

int f()
{
    // Do stuff

    if (condition == false)
        return -1;
    return 0;
}

int condition = f();

if (f != 0)
{
    // handle error
}

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

หากคุณต้องการทดสอบผลลัพธ์ของทุกฟังก์ชั่นให้ใช้รหัสส่งคืน

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

ในฟังก์ชั่นรหัสที่ออกแบบมาอย่างดีลึกอาจโยนและฟังก์ชั่นที่สูงขึ้นอาจจับ แต่ที่สำคัญคือฟังก์ชั่นมากมาย "ในระหว่าง" จะปราศจากภาระในการจัดการกับเงื่อนไขที่ยอดเยี่ยมเลย พวกเขาจะต้อง "ปลอดภัยยกเว้น" ซึ่งไม่ได้หมายความว่าพวกเขาจะต้องจับ

ฉันต้องการเพิ่มการสนทนานี้ว่าตั้งแต่ C ++ 11มันสมเหตุสมผลมากตราบใดที่ทุก ๆcatchบล็อกrethrowมีข้อยกเว้นจนถึงจุดที่สามารถทำได้ / ควรได้รับการจัดการ วิธีนี้ติดตามย้อนหลังสามารถสร้าง ฉันเชื่อว่าความคิดเห็นก่อนหน้านี้ล้าสมัยไปแล้ว

ใช้std::nested_exceptionและstd::throw_with_nested

มันอธิบายไว้ใน StackOverflow ที่นี่และที่นี่วิธีการบรรลุสิ่งนี้

เนื่องจากคุณสามารถทำได้ด้วยคลาสยกเว้นที่ได้รับคุณสามารถเพิ่มข้อมูลจำนวนมากลงใน backtrace! คุณอาจดูMWEของฉันบน GitHubด้วยที่ backtrace จะมีหน้าตาดังนี้:

Library API: Exception caught in function 'api_function'
Backtrace:
~/Git/mwe-cpp-exception/src/detail/Library.cpp:17 : library_function failed
~/Git/mwe-cpp-exception/src/detail/Library.cpp:13 : could not open file "nonexistent.txt"

ฉันได้รับ "โอกาส" ในการกอบกู้โครงการหลายโครงการและผู้บริหารแทนที่ทีมพัฒนาทั้งหมดเนื่องจากแอปมีข้อผิดพลาดมากเกินไปและผู้ใช้รู้สึกเบื่อกับปัญหาและวิ่งไปรอบ ๆ รหัสเหล่านี้ล้วน แต่มีการจัดการข้อผิดพลาดจากส่วนกลางที่ระดับแอพเหมือนกับคำตอบที่ได้รับการโหวตสูงสุด หากคำตอบนั้นเป็นวิธีปฏิบัติที่ดีที่สุดทำไมมันไม่ทำงานและอนุญาตให้ทีม dev ก่อนหน้านี้แก้ไขปัญหาได้ บางทีบางครั้งมันไม่ทำงาน? คำตอบข้างต้นไม่ได้พูดถึงว่านักพัฒนาใช้เวลาในการแก้ไขปัญหาเดียวนานแค่ไหน หากเวลาในการแก้ไขปัญหาคือการวัดที่สำคัญรหัสการใช้เครื่องมือกับ try..catch blocks คือแนวปฏิบัติที่ดีกว่า

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

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

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

วิธีการนี้ยังช่วยให้ devs ค้นหาและแก้ไขปัญหาต่อเนื่องในการผลิต! คุณต้องการดีบักโดยไม่มีดีบักเกอร์ในการผลิตหรือไม่? หรือคุณต้องการรับสายและรับอีเมลจากผู้ใช้ที่อารมณ์เสีย? วิธีนี้ช่วยให้คุณสามารถแก้ไขปัญหาก่อนที่คนอื่นจะรู้และไม่ต้องอีเมล, IM หรือ Slack พร้อมการสนับสนุนเนื่องจากทุกอย่างที่จำเป็นในการแก้ไขปัญหาอยู่ที่นั่น 95% ของปัญหาไม่จำเป็นต้องทำซ้ำ

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

บางครั้งนักพัฒนาเลือกที่จะโยนข้อยกเว้นสแต็กจาก catch catch แต่วิธีนี้ช้ากว่าโค้ดปกติ 100 เท่าที่ไม่ได้โยน แนะนำให้ใช้ Catch and release พร้อมการบันทึก

เทคนิคนี้ใช้เพื่อสร้างความเสถียรให้แอพที่ล้มเหลวทุกชั่วโมงสำหรับผู้ใช้ส่วนใหญ่ใน บริษัท Fortune 500 ที่พัฒนาโดย 12 Devs ในระยะเวลา 2 ปี การใช้ข้อยกเว้นที่แตกต่างกัน 3000 ข้อนี้ได้รับการระบุแก้ไขทดสอบและปรับใช้ใน 4 เดือน ค่าเฉลี่ยนี้จะแก้ไขโดยเฉลี่ยทุก 15 นาทีเป็นเวลา 4 เดือน

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

นอกจากคำแนะนำข้างต้นโดยส่วนตัวแล้วฉันลองใช้ + catch + throw; ด้วยเหตุผลดังต่อไปนี้:

1. ที่ขอบเขตของ coder ที่แตกต่างกันฉันใช้ try + catch + throw ในโค้ดที่เขียนด้วยตัวเองก่อนที่จะมีข้อยกเว้นถูกส่งไปยังผู้โทรที่เขียนโดยคนอื่นนี่ทำให้ฉันมีโอกาสที่จะทราบเงื่อนไขข้อผิดพลาดบางอย่างที่เกิดขึ้นในรหัสของฉัน สถานที่แห่งนี้อยู่ใกล้กับรหัสมากขึ้นซึ่งในขั้นต้นจะทำให้เกิดข้อยกเว้นยิ่งใกล้ชิดและง่ายต่อการค้นหาเหตุผล
2. ที่ขอบเขตของโมดูลแม้ว่าโมดูลที่แตกต่างกันอาจจะเขียนคนเดียวกันของฉัน
3. วัตถุประสงค์การเรียนรู้ + การดีบักในกรณีนี้ฉันใช้ catch (... ) ใน C ++ และ catch (Exception ex) ใน C #, สำหรับ C ++, ไลบรารีมาตรฐานไม่ส่งข้อยกเว้นมากเกินไปดังนั้นกรณีนี้หายากใน C ++ แต่สถานที่ทั่วไปใน C #, C # มีห้องสมุดขนาดใหญ่และลำดับชั้นของข้อยกเว้นที่เป็นผู้ใหญ่รหัสห้องสมุด C # จะมีข้อยกเว้นมากมายในทางทฤษฎี I (และคุณ) ควรรู้ข้อยกเว้นทุกประการจากฟังก์ชันที่คุณเรียกใช้และทราบเหตุผล / เหตุผลว่าทำไม ข้อยกเว้นเหล่านี้ถูกโยนและรู้วิธีจัดการกับมัน (ผ่านหรือจับและจัดการกับมันในสถานที่) อย่างสง่างาม น่าเสียดายที่ในความเป็นจริงมันยากมากที่จะรู้ทุกอย่างเกี่ยวกับข้อยกเว้นที่อาจเกิดขึ้นก่อนที่ฉันจะเขียนโค้ดหนึ่งบรรทัด ดังนั้นฉันจึงจับได้ทั้งหมดและให้โค้ดของฉันพูดออกเสียงโดยการบันทึก (ในสภาพแวดล้อมของผลิตภัณฑ์) / โต้ตอบการยืนยัน (ในสภาพแวดล้อมการพัฒนา) เมื่อมีข้อยกเว้นเกิดขึ้นจริง ด้วยวิธีนี้ฉันเพิ่มรหัสการจัดการข้อยกเว้นอย่างต่อเนื่อง ฉันรู้ว่ามันสับสนกับคำแนะนำที่ดี แต่ในความเป็นจริงมันใช้งานได้สำหรับฉันและฉันก็ไม่รู้วิธีที่ดีกว่าสำหรับปัญหานี้

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

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

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

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

ดังนั้นในระยะสั้นลอง / จับทำให้รหัสยากมากที่จะเข้าใจ

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

1. คุณสามารถใช้บล็อกนี้ที่คุณต้องการจัดการกับข้อยกเว้นหรือเพียงแค่คุณบอกว่าบล็อกของโค้ดที่เขียนอาจทำให้เกิดข้อยกเว้น
2. หากคุณต้องการกำจัดวัตถุของคุณทันทีหลังการใช้งานคุณสามารถใช้try-catchบล็อก