วิธีการจัดการข้อยกเว้นที่ไม่สามารถจัดการได้? (ยุติแอปพลิเคชั่น vs. รักษาชีวิต)

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

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

โครงการนี้เป็นแอปพลิเคชั่น. NET WPF ดังนั้นข้อเสนอที่อธิบายไว้อาจมีลักษณะเช่นนี้ (โปรดทราบว่านี่เป็นตัวอย่างแบบง่าย ๆ อาจเป็นไปได้ที่จะซ่อนรายละเอียดข้อยกเว้นจนกว่าผู้ใช้จะคลิกที่ "แสดงรายละเอียด" รายงานข้อผิดพลาดได้อย่างง่ายดาย):

public partial class App : Application
{
    public App()
    {
        DispatcherUnhandledException += OnDispatcherUnhandledException;
    }

    private void OnDispatcherUnhandledException(object sender, DispatcherUnhandledExceptionEventArgs e)
    {
        LogError(e.Exception);
        MessageBoxResult result = MessageBox.Show(
             $"Please help us fix it and contact support@example.com. Exception details: {e.Exception}" +
                        "We recommend to restart the application. " +
                        "Do you want to stop the application now? (Warning: Unsaved data gets lost).", 
            "Unexpected error occured.", MessageBoxButton.YesNo);

        // Setting 'Handled' to 'true' will prevent the application from terminating.
        e.Handled = result == MessageBoxResult.No;
    }

    private void LogError(Exception ex)
    {
        // Log to a log file...
    }
}

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

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

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

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

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

เริ่มต้นด้วยการวิเคราะห์ประเด็นต่อไปนี้:

• มีข้อมูลจำนวนเท่าใดที่สามารถสูญหายได้ในกรณีที่โปรแกรมถูกยกเลิก?

• การสูญเสียเช่นนี้มีความรุนแรงเพียงใดสำหรับผู้ใช้? ข้อมูลที่หายไปสามารถสร้างขึ้นใหม่ได้ในเวลาน้อยกว่า 5 นาทีหรือเรากำลังพูดถึงการสูญเสียวันทำงานหรือไม่?

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

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

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

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

ทำไม?

เพราะคุณไม่สามารถมีความมั่นใจในสถานะการสมัคร

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

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

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

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

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

แก้ไข:

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

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

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

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

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

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

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

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

ด้วยเหตุผลดังกล่าวคุณควรยกเลิกแอปพลิเคชัน

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

พวกเขาเกิดความคิดนี้ขึ้นหลังจากพบว่าบางระบบเริ่มทำงานได้เร็วขึ้นหลังจากเกิดความผิดพลาดมากกว่าหลังจากปิดระบบอย่างเป็นระเบียบ

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

มีเขียนขึ้นที่ดีเกี่ยวกับซอฟแวร์ผิดพลาดโดยเฉพาะวาเลอรีออโรร่าบน Linux ข่าวประจำสัปดาห์ ความคิดเห็นนี้ยังมีค่าอ่าน ยกตัวอย่างเช่นใครบางคนในความคิดเห็นอย่างถูกต้องชี้ให้เห็นว่าความคิดเหล่านั้นไม่ใช่เรื่องใหม่และในความเป็นจริงมากหรือน้อยเทียบเท่ากับหลักการออกแบบของแอปพลิเคชันที่ใช้ Erlang / OTP และแน่นอนเมื่อดูที่วันนี้อีก 10 ปีหลังจาก Valerie's และ 15 ปีหลังจากบทความต้นฉบับเราอาจสังเกตเห็นว่า hype บริการไมโครปัจจุบันกำลังทำการคิดค้นแนวคิดเดียวกันนี้อีกครั้ง การออกแบบศูนย์ข้อมูลระดับคลาวด์สมัยใหม่ก็เป็นตัวอย่างของความหยาบที่หยาบกว่า (คอมพิวเตอร์ทุกเครื่องสามารถพังเมื่อใดก็ได้โดยไม่กระทบต่อระบบ)

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

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

acquire lock
try
  update guarded resource
if exception
  invalidate lock
else
  release lock
end try

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

น่าเสียดายที่เจ้าหน้าที่รักษาความปลอดภัยของทรัพยากรดำเนินการผ่านIDisposable/ usingจะได้รับการปล่อยตัวเมื่อใดก็ตามที่ออกจากบล็อกที่มีการป้องกันโดยไม่ทราบว่าบล็อกดังกล่าวออกจากปกติหรือผิดปกติ ดังนั้นแม้ว่าจะมีเกณฑ์ที่ชัดเจนสำหรับเมื่อดำเนินการต่อหลังจากข้อยกเว้น แต่ก็ไม่มีวิธีบอกเวลาที่จะใช้

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

จากประสบการณ์ของฉันผู้ใช้หลายคนไม่ได้แจ้งให้ทราบใด ๆ แต่เพียงแค่แตะที่ไอคอนแอพอีกครั้ง

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