ಸಾಗಣೆಯು ವಿಫಲವಾದ ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕವನ್ನು ಲಾಗ್ ಮಾಡಬಹುದು, ಆದರೆ ಅಪ್ಲಿಕೇಶನ್ ಸಹ ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ದೋಷವನ್ನು ಸ್ವೀಕರಿಸಿ ನಿರ್ವಹಿಸುತ್ತದೆ. ಕೇವಲ ಲಾಗ್ ನಮೂದು ಅಪ್ಲಿಕೇಶನ್ ನ ನಿರ್ವಾಹಕವನ್ನು ಬಿಟ್ಟುಬಿಡಲಾಗಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ನಿಜವಾಗಿ ಚಂದಾದಾರಿಕೆ ಮಾಡಲಾದ ಸರಪಳಿಯಲ್ಲಿ ದೋಷ ಸಂಕೇತವನ್ನು ಅನುಸರಿಸಿ. ಕೇವಲ Mono ನಿರ್ಮಿಸುವ ಕೋಡ್ ಸುತ್ತಲಿನ try/catch ನಂತರದ ನೆಟ್ವರ್ಕ್ ವೈಫಲ್ಯದ ನಿರ್ವಹಣೆಗಿಂತ ಬೇರೆ ವ್ಯಾಪ್ತಿ.

ನಿರ್ವಾಹಕಪರಿಣಾಮ
doOnErrorದೋಷ ಮುಂದುವರಿಯುತ್ತಿರುವಾಗ ಅಡ್ಡಪರಿಣಾಮ ಮಾಡುತ್ತದೆ
onErrorMapಒಂದು ದೋಷವನ್ನು ಇನ್ನೊಂದು ದೋಷವಾಗಿ ಪರಿವರ್ತಿಸುತ್ತದೆ
onErrorResumeಪರ್ಯಾಯ ಪ್ರಕಾಶಕನಿಗೆ ಬದಲಾಗುತ್ತದೆ

ಅಪ್ಲಿಕೇಶನ್ ಗೆ ಬೇಕಾದ ವರ್ತನೆಯನ್ನು ಆಯ್ಕೆಮಾಡಿ. ಮೆಟ್ರಿಕ್ ದಾಖಲಿಸಲು ನಕಲಿ ಯಶಸ್ವಿ ವಿಷಯವನ್ನು ಹಿಂತಿರುಗಿಸುವ ಅಗತ್ಯವಿಲ್ಲ. ಪರ್ಯಾಯ ಪ್ರತಿಕ್ರಿಯೆ ಅಪ್ಲಿಕೇಶನ್ ನ ಉದ್ದೇಶಿತ ಫಲಿತಾಂಶವಾಗಿರಬೇಕು, ವಿಫಲ ಮಾರ್ಗವನ್ನು ಮರೆಮಾಡುವ ದಾರಿಯಲ್ಲ.

ಸಾಗಣೆ ವಿನಾಯಿತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಿದ HTTP ದೋಷ ಸ್ಥಿತಿಗಳಿಂದಲೂ ಪ್ರತ್ಯೇಕಿಸಿ. ಸಾಮಾನ್ಯ ಗಮ್ಯಸ್ಥಾನ ಪ್ರತಿಕ್ರಿಯೆ ಇರುವ ಮೊದಲೇ ಪ್ರಾಕ್ಸಿ ಸಂಪರ್ಕ ವಿಫಲವಾಗಬಹುದು, ಆದ್ದರಿಂದ HTTP ಸ್ಥಿತಿ ನಿರ್ವಾಹಕನಿಗೆ ಪರಿಶೀಲಿಸಲು ಏನೂ ಇಲ್ಲದಿರಬಹುದು. ಕೆಳ ಮಟ್ಟದ ವೈಫಲ್ಯವನ್ನು ಪತ್ತೆ ಮಾಡುವಾಗ WebClientRequestException ನ ಕಾರಣವನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ.

ಫಲಿತಾಂಶವನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡ ನಂತರವೇ ಲಾಗಿಂಗ್ ಹೊಂದಿಸಿ. ಇಡೀ ಸಾಗಣೆ ಲಾಗರ್ ಆಫ್ ಮಾಡುವುದರಿಂದ ನಂತರದ ಟೈಮೌಟ್, TLS ಸಮಸ್ಯೆ ಅಥವಾ ದೃಢೀಕರಣ ವೈಫಲ್ಯಕ್ಕೆ ಬೇಕಾದ ಸಾಕ್ಷ್ಯ ತೊಲಗಬಹುದು, ಪ್ರತಿಕ್ರಿಯಾತ್ಮಕ ಪೈಪ್ಲೈನ್ ವರ್ತನೆಯನ್ನು ಬದಲಿಸದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು