ฉันคิดว่าปัจจัยสำคัญคือลูกค้าของคุณคือใคร
หากเลเยอร์บริการของคุณเป็นเพียงแค่ขอบเขตสถาปัตยกรรมระหว่างเลเยอร์ในโครงการของคุณเองและเซอร์วิสลูกค้าอยู่ในขอบเขตความน่าเชื่อถือที่เหมือนกันดังนั้นจึงเป็นการผ่อนคลายเพื่อสิ่งต่าง ๆ และปล่อยให้ข้อยกเว้นที่ไม่ถูกตรวจสอบ
อย่างไรก็ตามสำหรับรหัสสาธารณะ บริการที่ถูกใช้โดยบุคคลที่สามหรือลูกค้าฉันคิดว่ามันสะอาดกว่าที่จะห่อข้อยกเว้นที่ไม่ได้ตรวจสอบด้วยข้อยกเว้นเชิงบริการส่วนใหญ่สำหรับข้อกังวลด้านความปลอดภัยอันดับสองสำหรับข้อต่อหลวมและสะอาดนามธรรม
ข้อยกเว้นเลเยอร์ข้อมูลไม่ควรทำให้ผู้ใช้ปลายทางของเว็บแอปพลิเคชันเข้าถึงผู้ใช้ปลายทางได้โดยตรง มันอาจมีข้อมูลภายในเกี่ยวกับสคีมาของคุณแบบสอบถามข้อมูลหมายเลขบรรทัดชื่อตัวแปรหรือฟังก์ชั่น ฯลฯ ข้อยกเว้นของผู้ใช้สามารถถูกทำให้สะอาดได้ในการตั้งค่าที่ปลอดภัย
ไคลเอ็นต์บริการภายนอกไม่เกี่ยวข้องกับรายละเอียดการใช้งานของคุณและไม่สามารถจัดการกับข้อยกเว้นที่ไม่ได้ตรวจสอบได้เนื่องจากเป็นปัญหาด้านสิ่งแวดล้อมหรือปัญหา ในแอปพลิเคชันที่ปลอดภัยข้อผิดพลาดของฐานข้อมูลนั้นไม่ปลอดภัยพอที่จะเผยแพร่OracleException - ORA-01234 - ...
ซึ่งอาจเป็นตารางที่ 3 ที่ถูกแทรก ลูกค้าควรได้รับอนุญาตให้จัดการกับข้อยกเว้นที่ตรวจสอบ / คาดว่าจะสามารถจัดการได้และปฏิบัติต่อทุกสิ่งเป็นรายงานบั๊กที่เป็นไปได้ สัญญาการให้บริการของคุณควรเป็นสิ่งที่เป็นนามธรรมที่สอดคล้องและเป็นธุรกรรม หากไม่สามารถทำอะไรเกี่ยวกับข้อยกเว้นได้สิ่งที่มีประโยชน์เพียงอย่างเดียวคือให้รายงานข้อผิดพลาดแก่คุณ. คุณมีความสามารถในการบันทึกข้อยกเว้นแล้วเหตุใดจึงทำให้ผู้ใช้ปลายทางของคุณต้องมีรายละเอียด แอปของคุณสามารถตรวจสอบได้เพื่อให้คุณทราบเกี่ยวกับข้อยกเว้นที่ไม่ได้ตรวจสอบก่อนที่ผู้ใช้จะรายงาน
มันไม่เคยโอเคที่จะกินข้อยกเว้นหรือฉันเป็นแฟนของข้อยกเว้นที่ตรวจสอบ แต่ฉันชอบที่จะมีแผนที่เหมาะสมกับลักษณะของผลิตภัณฑ์โดยรวม