เหตุใด "บันทึกและโยน" จึงถือเป็นการต่อต้านรูปแบบ [ปิด]

คำถามนี้เกิดจากการอภิปรายในบทความนี้ซึ่งฉันไม่ได้รับคำตอบที่ดีเลย

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

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

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

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

Log-and-throw เป็นรูปแบบที่ดีหากเอนทิตีที่จับและสร้างข้อยกเว้นขึ้นมาใหม่มีเหตุผลที่เชื่อได้ว่ามีข้อมูลที่จะไม่ถูกบันทึกเพิ่มเติมในกลุ่มการโทร - อย่างน้อยก็ไม่ใช่ในรูปแบบที่ต้องการมากที่สุด สาเหตุสองประการนี้อาจเกิดขึ้น:

1. ข้อยกเว้นอาจถูกจับและเปลี่ยนใหม่ที่ขอบเขตของชั้นแอปพลิเคชันและอาจมีข้อมูลที่เป็นสิทธิพิเศษ มันจะเป็นการไม่ดีสำหรับเลเยอร์ฐานข้อมูลที่อนุญาตให้มีข้อยกเว้นเช่น "พยายามเพิ่มคีย์ที่ซ้ำกัน 'fnord' ลงในฟิลด์ 'ผู้ใช้' เพื่อเข้าถึงเลเยอร์แอปพลิเคชันภายนอก (ซึ่งอาจทำให้ผู้ใช้เห็น) แต่ อาจมีประโยชน์สำหรับส่วนภายในของฐานข้อมูลในการทิ้งข้อยกเว้นดังกล่าวและอินเทอร์เฟซของแอปพลิเคชันเพื่อตรวจจับบันทึกอย่างปลอดภัยและสร้างข้อยกเว้นที่อธิบายได้น้อยกว่า
2. ข้อยกเว้นอาจเป็นข้อยกเว้นที่ชั้นนอกคาดว่าจะจัดการได้โดยไม่ต้องบันทึก แต่ชั้นในอาจรู้บางอย่างที่ชั้นนอกไม่แนะนำว่าการบันทึกอาจเป็นประโยชน์ ตามตัวอย่างคร่าวๆอาจมีการตั้งโปรแกรมเลเยอร์แอปพลิเคชันกลางให้ลองเชื่อมต่อกับเซิร์ฟเวอร์หนึ่งและหากไม่ได้ผลให้ลองอีกครั้ง การทำให้บันทึกของแอปพลิเคชันเต็มไปด้วยข้อความ "การเชื่อมต่อล้มเหลว" ในขณะที่เซิร์ฟเวอร์หยุดทำงานเพื่อการบำรุงรักษาอาจไม่เป็นประโยชน์โดยเฉพาะอย่างยิ่งเนื่องจาก - จากมุมมองของแอปพลิเคชันทุกอย่างทำงานได้ดี อาจเป็นประโยชน์ในการส่งต่อข้อมูลเกี่ยวกับความล้มเหลวในการเชื่อมต่อไปยังทรัพยากรการบันทึกที่เชื่อมโยงกับเซิร์ฟเวอร์ซึ่งจะสามารถกรองบันทึกเพื่อสร้างรายงานเมื่อเซิร์ฟเวอร์ขึ้นและลงเมื่อเทียบกับบันทึกของทุกครั้งที่พยายามเชื่อมต่อ .

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

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

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

การบันทึกและโยน IMO เป็นการละเมิดหลักการของการเซอร์ไพรส์น้อยที่สุดอย่างชัดเจน

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