การจับข้อยกเว้นทั่วไปเป็นสิ่งที่ไม่ดีจริง ๆ หรือ

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

CA1031: อย่าตรวจจับชนิดข้อยกเว้นทั่วไป

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

ตัวอย่างเช่นถ้า Foo เรียกบาร์และ Foo จำเป็นต้องหยุดการประมวลผลโดยไม่คำนึงถึงประเภทของข้อยกเว้นที่เกิดจาก Bar มีข้อได้เปรียบอะไรบ้างในการระบุประเภทของข้อยกเว้นที่ฉันจับได้

อาจเป็นตัวอย่างที่ดีกว่า:

public void Foo()
{
    // Some logic here.
    LogUtility.Log("some message");
}

public static void Log()
{
    try
    {
        // Actual logging here.
    }
    catch (Exception ex)
    {
        // Eat it. Logging failures shouldn't stop us from processing.
    }
}

หากคุณไม่ได้รับการยกเว้นทั่วไปที่นี่คุณต้องรับการยกเว้นทุกประเภทที่เป็นไปได้ Patrick มีจุดดีที่OutOfMemoryExceptionไม่ควรจัดการด้วยวิธีนี้ แล้วถ้าฉันต้องการเพิกเฉยทุกข้อยกเว้นOutOfMemoryExceptionล่ะ?

โดยทั่วไปกฎเหล่านี้เป็นความคิดที่ดีและควรปฏิบัติตาม

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

บนเคาน์เตอร์ด้านของการโต้แย้ง

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

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

มีข้อยกเว้นบางประการที่คุณสามารถจัดการได้:

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

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

วงนอกชั้นบนสุดควรมีสิ่งใดสิ่งหนึ่งที่สามารถพิมพ์ได้แล้วตายอย่างน่ากลัวความรุนแรงและความตายของ NOISY (เพราะสิ่งนี้ไม่ควรเกิดขึ้นและมีคนต้องการได้ยิน)

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

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

ความเป็นไปได้ทั้งสองนั้นไม่ได้มีความพิเศษเฉพาะตัว

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

try
{
    this.Foo();
}
catch (BarException ex)
{
    Console.WriteLine("Foo has barred!");
}
catch (BazException ex)
{
    Console.WriteLine("Foo has bazzed!");
}
catch (Exception ex)
{
    Console.WriteLine("Unknown exception on Foo!");
    throw;
}

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

แก้ไข: ด้วยเหตุผลที่ระบุไว้ในความคิดเห็นให้เพิ่มใหม่ในการจับครั้งสุดท้าย

ฉันได้ไตร่ตรองอย่างเดียวกันเมื่อเร็ว ๆ นี้และข้อสรุปเบื้องต้นของฉันคือคำถามที่เกิดขึ้นเนื่องจากลำดับชั้นข้อยกเว้นของ. NETนั้นเกิดความสับสนอย่างรุนแรง

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

จากนั้นมี IMNSHO สำคัญเพลี่ยงพล้ำของการมีSEHExceptionการสืบทอดมา (ผ่านExternalException) SystemExceptionจึงทำให้มันเป็น "ปกติ"SystemExceptionเมื่อคุณได้รับSEHExceptionคุณต้องการที่จะเขียนการถ่ายโอนข้อมูลและยุติให้เร็วที่สุดเท่าที่คุณสามารถ - และเริ่มต้นด้วย .NET 4 อย่างน้อยบางส่วนข้อยกเว้น SEH ได้รับการพิจารณาว่าเป็นข้อยกเว้นของรัฐที่เสียหายซึ่งจะไม่ถูกดักจับ สิ่งที่ดีและความจริงที่ทำให้CA1031กฎไร้ประโยชน์มากขึ้นเพราะตอนนี้คนขี้เกียจของคุณcatch (Exception)จะไม่ได้รับสิ่งที่แย่ที่สุดเหล่านี้อยู่ดี

จากนั้นดูเหมือนว่าสิ่งอื่น ๆ ของ Framework จะค่อนข้างไม่สอดคล้องกันทั้งExceptionทางตรงและทางผ่านSystemExceptionทำให้มีความพยายามในการจัดกลุ่มคำสั่งย่อยโดยบางสิ่งบางอย่างเช่นความรุนแรงที่สงสัย

มีชิ้นส่วนโดย Mr. Lippert ที่C#มีชื่อเสียงเรียกว่าVexing Exceptionซึ่งเขาวางหมวดหมู่ของข้อยกเว้นที่มีประโยชน์บางอย่าง: คุณสามารถโต้แย้งว่าคุณต้องการเพียงแค่จับ "exogenous" ยกเว้น ... C#ภาษาและการออกแบบของ. NET ข้อยกเว้นของกรอบทำให้ไม่สามารถ "จับเฉพาะสิ่งภายนอก" ในลักษณะรัดกุม _{(และเช่นการOutOfMemoryExceptionอาจได้เป็นอย่างดีจะเป็นข้อผิดพลาดที่สามารถกู้คืนได้ทั้งหมดตามปกติสำหรับ API ที่มีการจัดสรรบัฟเฟอร์ที่มีขนาดใหญ่อย่างใด)}

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

มีอย่างน้อย 4 วิธีในการจัดการกับการจับที่ถูกกฎหมายExceptionและCA1031ดูเหมือนว่าจะจัดการกับพวกเขาเพียงคนเดียวเท่านั้น (นั่นคือกรณีการโยนอีกครั้ง)

ตามบันทึกข้างมี C # 6 คุณลักษณะที่เรียกว่ากรองข้อยกเว้นที่จะทำให้เล็กน้อยที่ถูกต้องมากขึ้นอีกครั้งตั้งแต่นั้นมาคุณจะสามารถที่จะถูกต้องอย่างถูกต้องถูกต้องกรองข้อยกเว้นที่คุณต้องการที่จะจับและมีเหตุผลน้อยที่จะเขียนไม่ได้กรองCA1031catch (Exception)

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

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

ดูที่คำตอบ SO นี้สำหรับการอ่านเพิ่มเติม

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

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

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

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

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

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

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

ตัวอย่างเช่นถ้า Foo เรียกบาร์และ Foo จำเป็นต้องหยุดการประมวลผลโดยไม่คำนึงถึงประเภทของข้อยกเว้นที่เกิดจาก Bar มีข้อได้เปรียบอะไรบ้างในการระบุประเภทของข้อยกเว้นที่ฉันจับได้

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

ดังนั้นถ้าฉันต้องการละเว้นข้อยกเว้นทุกอย่างยกเว้น OutOfMemoryException

IMHO นี่เป็นวิธีที่ผิดที่จะคิดเกี่ยวกับการจัดการข้อยกเว้น คุณควรดำเนินการกับบัญชีขาว (ตรวจจับประเภท A และ B) ไม่ใช่บัญชีดำ (ยกเว้นทุกข้อยกเว้นนอกเหนือจาก X)

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

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

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

คุณไม่ต้องการรับการแจ้งเตือนทันทีว่ามีปัญหานี้หรือไม่ดังนั้นคุณสามารถแก้ไขได้ การกลืนข้อยกเว้นหมายความว่าคุณไม่เคยรู้ว่ามีบางอย่างผิดปกติ

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

ฉันต้องการพูดถึงเรื่องนี้จากมุมมองเชิงตรรกะมากกว่ามุมมองเชิงเทคนิค

ตอนนี้ฉันต้องเปลี่ยนรหัสเพื่อจัดการข้อยกเว้นใหม่นั้น

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

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

นี่คือส่วนความงาม: ไม่คุณไม่ได้ทำ

"ดังนั้นฉันสามารถดูวิธีอื่นและมีสิ่งที่น่ารังเกียจปรากฏขึ้นกวาดใต้พรมโดยอัตโนมัติและทำได้ด้วยหรือไม่"

ไม่นั่นไม่ใช่วิธีการทำงานเช่นกัน

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

"แต่ ... แต่ ... แล้วถ้าอย่างนั้นข้อยกเว้นอย่างอื่นที่ฉันไม่สนใจอาจทำให้งานของฉันล้มเหลว!"

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

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

คุณไม่ควรรับข้อยกเว้นทั่วไปและพยายามดำเนินการต่อ