เมื่อใดจะเริ่มเขียนการจัดการข้อยกเว้นการบันทึก

คุณจะเริ่มเขียนโค้ดจัดการข้อยกเว้นเมื่อใด คุณเริ่มเขียนคำสั่งการบันทึกเมื่อใด

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

การแก้ไข: โครงการ Windows Forms โครงการ: UI, BusinessRules, DataHandlers

ดังนั้นคุณจะไปเกี่ยวกับการเขียน DataHandlers ของคุณซึ่งการจัดการข้อมูลของคุณเช่นสร้างอ่านอัปเดตลบก่อน

จากนั้นติดตามกฎธุรกิจของคุณ

จากนั้น UI ของคุณหรือการเปลี่ยนแปลงอื่น ๆ ข้างต้น

ทดสอบแอปพลิเคชันของคุณสำหรับการใช้งาน

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

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

PS: ในClean Codeของหนังสือพวกเขาบอกว่าเขียนบล็อกtry-catch-สุดท้ายของคุณก่อน นั่นทำให้ฉันถามคำถามนี้

คุณเขียนรหัสการจัดการข้อยกเว้นเมื่อคุณเขียนสิ่งที่เรียกสิ่งที่อาจทำให้เกิดข้อยกเว้น

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

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

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

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

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

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

ขึ้นอยู่กับสิ่งที่คุณกำลังทำ

สำหรับข้อยกเว้น:

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

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

ไม่ว่าในกรณีใดถ้าคุณไม่มีอะไรเกี่ยวข้องกับข้อผิดพลาดลองปล่อยให้มันลอยขึ้น (ไม่มีตัวจัดการ)

สำหรับการบันทึก:

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

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

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

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

เขียนเมื่อคุณต้องการ แต่ออกแบบเพื่อรวมไว้ตั้งแต่เริ่มต้น

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