अपवाद हैंडलिंग के कुछ नियम हैं जिन्हें आपको ध्यान में रखना चाहिए। लेकिन पहले, आपको यह याद रखना होगा कि अपवाद कोड द्वारा उजागर किए गए इंटरफ़ेस का हिस्सा हैं ; उन्हें दस्तावेज दें । यह विशेष रूप से महत्वपूर्ण है जब इंटरफ़ेस एक सार्वजनिक है, ज़ाहिर है, लेकिन निजी इंटरफेस में भी यह बहुत अच्छा विचार है।
अपवादों को केवल उस बिंदु पर नियंत्रित किया जाना चाहिए जहां कोड उनके साथ कुछ समझदार हो सकता है। सबसे खराब हैंडलिंग विकल्प उनके बारे में कुछ भी नहीं करना है, जो केवल तभी किया जाना चाहिए जब वह बिल्कुल सही विकल्प हो। (जब मेरे कोड में ऐसी स्थिति होती है, तो मैं उस प्रभाव के लिए एक टिप्पणी शामिल करता हूं ताकि मैं जानता हूं कि खाली शरीर के बारे में चिंता न करें।)
दूसरा सबसे खराब विकल्प मूल कारण के बिना असंबंधित अपवाद को फेंकना है। यहाँ मुद्दा यह है कि समस्या का निदान करने की अनुमति देने वाले मूल अपवाद के भीतर की जानकारी खो जाती है; आप कुछ ऐसा बना रहे हैं जिसके साथ कोई भी कुछ भी नहीं कर सकता (शिकायत के अलावा "यह काम नहीं करता है", और हम सभी जानते हैं कि हम उन बग रिपोर्ट से कैसे नफरत करते हैं )।
बहुत बेहतर अपवाद लॉगिंग है। इससे किसी को पता चलता है कि समस्या क्या है और इसे ठीक कर दें, लेकिन आपको केवल उस बिंदु पर अपवाद को लॉग इन करना चाहिए, जहां यह अन्यथा खो जाएगा या बाहरी कनेक्शन पर रिपोर्ट किया जाएगा। ऐसा इसलिए नहीं है क्योंकि अधिक बार लॉग इन करना एक बड़ी समस्या है, बल्कि इसलिए कि अत्यधिक लॉगिंग का मतलब है कि आपको अधिक जानकारी के बिना लॉग इन का अधिक स्थान प्राप्त करना है। एक बार जब आप अपवाद को लॉग कर लेते हैं, तो आप उपयोगकर्ता / ग्राहक को एक अच्छे विवेक के साथ एक पूर्वापेक्षा की रिपोर्ट कर सकते हैं (जब तक कि आप पीढ़ी का समय भी शामिल करते हैं - या अन्य सहसंबंध पहचानकर्ता - उस रिपोर्ट में ताकि लघु संस्करण का मिलान किया जा सके यदि आवश्यक हो तो विस्तार के साथ)।
सबसे अच्छा विकल्प, ज़ाहिर है, अपवाद को पूरी तरह से संभालने के लिए, अपनी संपूर्णता में त्रुटि स्थिति से निपटना। यदि आप ऐसा कर सकते हैं, तो हर तरह से कर सकते हैं! इसका मतलब यह भी हो सकता है कि आप अपवाद को लॉग इन करने से बच सकते हैं।
एक अपवाद को संभालने का एक तरीका एक और अपवाद है जो समस्या के उच्च-स्तरीय विवरण प्रदान करता है (उदाहरण के लिए, " failed to initialize" के बजाय " index out of bounds")। यह एक अच्छा पैटर्न है जब तक आप अपवाद के कारण के बारे में जानकारी नहीं खोते हैं; causeउच्च-स्तरीय अपवाद को इनिशियलाइज़ करने के लिए विस्तृत अपवाद का उपयोग करें या विवरण लॉग करें (जैसा कि ऊपर चर्चा की गई है)। लॉगिंग सबसे उपयुक्त है जब आप एक अंतर-प्रक्रिया सीमा को पार करने वाले होते हैं, जैसे कि IPC कॉल, क्योंकि इस बात की कोई गारंटी नहीं है कि कनेक्शन के दूसरे छोर पर निम्न-स्तरीय अपवाद वर्ग सभी पर मौजूद होगा। एक आंतरिक सीमा को पार करते समय एक संलग्न कारण के रूप में रखना सबसे उपयुक्त है।
आपके द्वारा देखा गया एक और पैटर्न कैच-एंड-रिलीज़ है:
try {
// ...
} catch (FooException e) {
throw e;
}
यह एक विरोधी प्रतिमान है जब तक कि आपको अन्य catchखंडों से प्रकार की बाधाएं नहीं मिली हैं, इसका मतलब है कि आप अपवाद को अपने दम पर अतीत में जाने नहीं दे सकते। तब यह जावा की एक बदसूरत विशेषता है।
चेक किए गए अपवादों के बीच कोई वास्तविक अंतर नहीं है और इस तथ्य के अलावा अनियंत्रित हैं कि आपको चेक अपवादों को घोषित करना चाहिए जो क्रॉस विधि की सीमाएं हैं। @throwsयदि आप जानते हैं कि आपके कोड के द्वारा जानबूझकर फेंका जा रहा है, तो यह अभी भी एक अच्छा विचार है कि अनियंत्रित अपवादों ( javadoc टिप्पणी के साथ) को दस्तावेज़ित किया जाए । जानबूझकर java.lang.Errorया उसके उपवर्गों को न फेंकें (जब तक कि आप एक जेवीएम कार्यान्वयन नहीं लिख रहे हों)।
राय: एक अप्रत्याशित त्रुटि का मामला हमेशा आपके कोड में बग का प्रतिनिधित्व करता है। चेक किए गए अपवाद इस खतरे को प्रबंधित करने का एक तरीका है, और जहां डेवलपर्स जानबूझकर त्रुटि मामलों से निपटने की परेशानी से बचने के तरीके के रूप में अनियंत्रित अपवादों का उपयोग कर रहे हैं, आप बहुत अधिक तकनीकी ऋण का निर्माण कर रहे हैं जिसे आपको कुछ समय में साफ करना होगा यदि आप मजबूत कोड चाहते हैं। मैला त्रुटि हैंडलिंग अनप्रोफेशनल है (और प्रोग्रामर वास्तव में कितना अच्छा है यह निर्धारित करने के लिए त्रुटि हैंडलिंग एक अच्छा तरीका है)।