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

ติดตามสัญญาณข้อผิดพลาดในเชนที่สมัครรับจริง try/catch ที่ล้อมรอบโค้ดซึ่งเพียงสร้าง Mono นั้นเป็นขอบเขตที่ต่างจากการจัดการความล้มเหลวของเครือข่ายในภายหลัง

โอเปอเรเตอร์ผลกระทบ
doOnErrorทำผลข้างเคียงขณะที่ข้อผิดพลาดยังดำเนินอยู่
onErrorMapแปลงข้อผิดพลาดหนึ่งเป็นข้อผิดพลาดอื่น
onErrorResumeสลับไปยังผู้เผยแพร่ทางเลือก

เลือกพฤติกรรมที่แอปพลิเคชันต้องการ การบันทึกเมตริกไม่จำเป็นต้องส่งคืนเนื้อหาที่สำเร็จปลอม การตอบกลับทางเลือกควรเป็นผลลัพธ์ที่แอปพลิเคชันตั้งใจไว้ ไม่ใช่วิธีซ่อนเส้นทางที่ล้มเหลว

แยกข้อยกเว้นของ transport ออกจากสถานะข้อผิดพลาด HTTP ที่ได้รับด้วย การเชื่อมต่อพร็อกซีอาจล้มเหลวก่อนที่การตอบกลับปกติจากปลายทางจะเกิดขึ้น ตัวจัดการสถานะ HTTP จึงอาจไม่มีอะไรให้ตรวจสอบ รักษาสาเหตุของ WebClientRequestException ไว้เมื่อวินิจฉัยความล้มเหลวระดับล่าง

ปรับการบันทึก log หลังจากเข้าใจผลลัพธ์แล้วเท่านั้น การปิด logger ของ transport ทั้งหมดอาจลบหลักฐานที่จำเป็นสำหรับการหมดเวลา ปัญหา TLS หรือความล้มเหลวในการพิสูจน์ตัวตนในภายหลัง โดยไม่เปลี่ยนพฤติกรรมของไปป์ไลน์แบบ reactive

บทความที่เกี่ยวข้อง