जावा के लोग अपवादों का चुपचाप सेवन क्यों करते हैं?

Question 1

मैंने पहले कभी कोई गंभीर जावा कोडिंग नहीं की थी, लेकिन मैंने अपने मौजूदा कौशल (डेल्फी और सी #) के आधार पर वाक्यविन्यास, पुस्तकालयों और अवधारणाओं को सीखा। एक बात जो मुझे शायद ही समझ में आती है, वह यह है कि मैंने इतना कोड देखा है कि चुपचाप printStackTraceइस तरह के अपवादों का उपभोग करते हैं :

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            e.printStackTrace();
        }
    }

इसी तरह का कोड लगभग हर जावा लेख और परियोजना में एक है जैसे मैं भाग गया। मेरे ज्ञान के आधार पर यह बहुत बुरा है। अपवाद को हमेशा इस तरह बाहरी संदर्भ में भेजा जाना चाहिए:

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            e.printStackTrace();
            throw new AssertionError(e);
        }
    }

ज्यादातर समय अपवाद को सबसे बाहरी लूप में संभाला जाना चाहिए जो अंतर्निहित ढांचे (उदाहरण के लिए जावा स्विंग) से संबंधित है। यह जावा दुनिया में इस तरह कोड करने के लिए आदर्श क्यों दिखता है? मैं चकरा गया हूं।

अपनी पृष्ठभूमि के आधार पर, मैं पूरी तरह से PrintStackTrace को निकालना पसंद करूंगा । मैं बस एक अनहेल्ड उर्फ RuntimeException(या, और भी बेहतर AssertionError) के रूप में फिर से उखाड़ फेंकूंगा , फिर इसे पकड़कर सबसे उपयुक्त स्थान पर लॉग इन करूंगा : फ्रेमवर्क सबसे बाहरी लूप।

    public void process() {
        try {
            System.out.println("test");
        } catch(Exception e) {
            throw new AssertionError(e);
        }
    }

Question 2

मैंने हमेशा सोचा है, कि निम्नलिखित परिदृश्य के समान है:

“एक आदमी को गोली मार दी जाती है।

वह अपनी सांस लेता है और एक बस लेने के लिए पर्याप्त ताकत है।

10 मील बाद आदमी बस से उतर जाता है, एक-दो ब्लॉक चलता है और मर जाता है। "

जब पुलिस को शव मिलता है, तो उनके पास कोई सुराग नहीं होता है कि अभी क्या हुआ है। वे अंततः हो सकता है लेकिन यह बहुत कठिन है।

बेहतर है:

"एक आदमी को गोली लग जाती है और वह तुरंत मर जाता है, और शरीर ठीक उसी जगह पर होता है जहां हत्या अभी हुई है।"

जब पुलिस पहुंचती है, तो सभी सबूत जगह पर होते हैं।

यदि एक प्रणाली को विफल करना है, तो बेहतर है कि तेजी से विफल हो

प्रश्न का समाधान:

अज्ञान।
आलस

संपादित करें:

बेशक, कैच सेक्शन उपयोगी है।

यदि अपवाद के साथ कुछ किया जा सकता है, तो यह वह जगह है जहां इसे किया जाना चाहिए।

संभवतः यह दिए गए कोड के लिए अपवाद नहीं है, शायद यह कुछ ऐसा है जो अपेक्षित है (और मेरे सादृश्य में बुलेटप्रूफ जैकेट की तरह है, और आदमी पहले शॉट के लिए इंतजार कर रहा था)।

और हां, कैच को थ्रो अपवाद के लिए इस्तेमाल किया जा सकता है

Question 3

आमतौर पर यह उस आईडीई के कारण एक सहायक 'क्विक फिक्स' की पेशकश करता है, जो उस अपवाद को संभालने के साथ कोशिश करने वाले ब्लॉक में आपत्तिजनक कोड को लपेटता है। विचार यह है कि आप वास्तव में कुछ करते हैं, लेकिन आलसी डेवलपर्स नहीं करते हैं।

यह बुरा रूप है, इसमें कोई शक नहीं।

Question 4

यह एक क्लासिक स्ट्रॉ मैन तर्क है । printStackTrace()एक डीबगिंग सहायता है। यदि आप एक ब्लॉग पर या एक पत्रिका में यह देखा है तो इसकी वजह थी कि लेखक एक बिंदु illustrating में अधिक रुचि थी अन्य अपवाद हैंडलिंग से। यदि आपने इसे उत्पादन कोड में देखा, तो उस कोड का डेवलपर अज्ञानी या आलसी था, इससे ज्यादा कुछ नहीं। इसे "जावा दुनिया" में आम प्रथा के उदाहरण के रूप में नहीं रखा जाना चाहिए।

Question 5

जावा आपको सभी अपवादों को स्पष्ट रूप से संभालने के लिए मजबूर करता है। यदि एक विधि जिसे आपके कोड कॉल को FooException और BarException को फेंकने के लिए घोषित किया जाता है, तो आपका कोड उन अपवादों को संभालना (या फेंकना) है। इसका एकमात्र अपवाद RuntimeException है , जो निंजा की तरह चुप है।
प्रोग्रामर के बहुत सारे आलसी (स्वयं शामिल हैं), और स्टैक ट्रेस को प्रिंट करना बहुत आसान है।

Question 6

मुझे लगता है कि ऐसा होने के अक्सर 2 कारण हैं

प्रोग्रामर आलसी था
प्रोग्रामर वहाँ एक प्रवेश बिंदु को घटक में (सही या गलत तरीके से) संरक्षित करना चाहता था

मैं नहीं मानता कि यह जावा तक सीमित एक घटना है। मैंने C # और VB.Net में भी अक्सर ऐसी कोडिंग देखी है।

सतह पर यह काफी चौंकाने वाला है और भयानक लग रहा है। लेकिन वास्तव में यह कोई नई बात नहीं है। यह सी ++ अनुप्रयोगों में हर समय होता है जो त्रुटि कोड रिटर्न मान बनाम अपवाद का उपयोग करते हैं। हालांकि यह अंतर यह है कि संभावित रूप से घातक रिटर्न वैल्यू को अनदेखा करना वास्तव में किसी ऐसे फ़ंक्शन को कॉल करने की तुलना में अलग नहीं दिखता है जो शून्य देता है।

Foo* pFoo = ...;
pFoo->SomeMethod(); // Void or swallowing errors, who knows?

यह कोड बेहतर दिखता है, लेकिन अगर SomeMethod () कहने के लिए एक HResult लौटा था, यह शब्दार्थ एक अपवाद को निगलने से अलग नहीं होगा।

Question 7

क्योंकि चेक किया गया अपवाद एक असफल प्रयोग है

(शायद PrintStackTrace () असली समस्या है ?)

Question 8

मेरा कहना है कि मैं इस प्रकार के लचर त्रुटि से निपटने वाले व्यवहार से थोड़ा नाराज हूं, जो जावा प्रोग्रामर के लिए मौलिक है। निश्चित रूप से, जावा प्रोग्रामर हर दूसरे प्रोग्रामर की तरह आलसी हो सकते हैं, और जावा की एक लोकप्रिय भाषा है, इसलिए आपको शायद बहुत सारे कोड अपवाद दिखाई देंगे।

इसके अलावा, जैसा कि कहीं और बताया गया है, चेक अपवादों के जावा के लागू किए गए घोषणा के साथ समझने योग्य कुंठाएं हैं, हालांकि व्यक्तिगत रूप से मुझे इससे कोई समस्या नहीं है।

मेरे पास एक समस्या है, मुझे लगता है कि आप इस संदर्भ पर विचार किए बिना वेब पर लेख और कोड स्निपेट के एक समूह के माध्यम से उछल रहे हैं। सच्चाई यह है, जब आप एक तकनीकी लेख लिखकर यह बताने की कोशिश कर रहे हैं कि कुछ विशेष एपीआई कैसे काम करते हैं, या किसी चीज़ के साथ कैसे शुरू किया जाता है, तो आपको कोड के कुछ पहलुओं को छोड़ देने की बहुत संभावना है - त्रुटि हैंडलिंग जो सीधे नहीं है आप जो प्रदर्शन कर रहे हैं, वह निपटान के लिए एक संभावित उम्मीदवार है, खासकर यदि अपवाद उदाहरण परिदृश्य में होने की संभावना नहीं है।

जो लोग उस प्रकृति के लेख लिखते हैं, उन्हें उचित संकेत-से-शोर अनुपात बनाए रखना पड़ता है, और बल्कि निष्पक्ष रूप से, मुझे लगता है, इसका मतलब है कि उन्हें यह मानना होगा कि आप जिस भाषा में विकसित हो रहे हैं उसके बारे में कुछ मूल बातें जानते हैं; त्रुटियों से ठीक से कैसे निपटें, और अन्य चीजों का एक गुच्छा। यदि आप एक लेख भर में आते हैं और उचित त्रुटि जाँच में कमी की सूचना देते हैं, तो यह ठीक है; बस यह सुनिश्चित करें कि जब आप अपने उत्पादन कोड में उन विचारों को शामिल करते हैं (लेकिन निश्चित रूप से, कभी भी सटीक कोड ही नहीं, सही?), तो आप उन सभी बिट्स और बॉब्स से निपटेंगे जो लेखक ने समझदारी से छोड़ दिए हैं, एक तरीके से जो सबसे अधिक है आप जो विकसित कर रहे हैं उसके अनुकूल।

मेरे पास बहुत उच्च-स्तरीय परिचयात्मक लेखों के साथ एक समस्या है जो ऐसे मुद्दों पर बिना हवा दिए उन्हें कभी वापस नहीं करते हैं, लेकिन कृपया ध्यान रखें कि त्रुटि से निपटने के बारे में जावा प्रोग्रामर्स की कुछ विशेष "मानसिकता" नहीं है; मुझे आपके बहुत सारे प्रिय C # प्रोग्रामर्स के बारे में पता है जो उनकी सभी समस्याओं से निपटने में परेशान नहीं हैं।

Question 9

एक System.out प्रिंट या e.printStackTrace () - जिसका अर्थ है System.out का उपयोग आमतौर पर एक लाल झंडा है जिसका अर्थ है कि कोई मेहनती काम करने के लिए परेशान नहीं करता है। डेस्कटॉप जावा एप्लिकेशन को छोड़कर, अधिकांश जावा ऐप्स लॉगिंग का उपयोग करने से बेहतर हैं।

यदि किसी विधि के लिए विफलता मोड एक नो-ऑपरेशन है, तो एक अपवाद खाने के लिए पूरी तरह से ठीक है, चाहे आप कारण (और अस्तित्व) रिकॉर्ड करें या नहीं। आम तौर पर, हालांकि, कैच क्लॉज़ को किसी प्रकार की असाधारण कार्रवाई करनी चाहिए।

एक अपवाद को रोकना कुछ ऐसा है जो तब किया जाता है जब आप या तो काम के हिस्से को साफ करने के लिए कैच का उपयोग ऐसे स्तर पर करते हैं जहां आवश्यक जानकारी अभी भी उपलब्ध है या जब आपको अपवाद को बदलने की आवश्यकता होती है, तो कॉल करने वाले के लिए अधिक उत्तरदायी।

Question 10

यह केवल चुपचाप भस्म हो जाता है अगर वास्तव में कैच ब्लॉक खाली है।

जहाँ तक लेखों की बात है वे अपवादों से निपटने के अलावा कुछ अन्य बिंदु साबित करने में शायद अधिक दिलचस्प हैं। वे बस इस बिंदु पर सीधे जाना चाहते हैं और सबसे कम संभव कोड हैं।

जाहिर है कि आप सही हैं, अपवादों को कम से कम लॉग इन किया जाना चाहिए, अगर वे 'अनदेखा' होने जा रहे हैं।

Question 11

जैसा कि दूसरों ने बताया है, आप जो देखते हैं, वह तीन कारणों में से एक है:

IDE ने ट्राई-कैच ब्लॉक को जेनरेट किया
- कोड को कॉपी और पेस्ट किया गया था
- डेवलपर ने स्टैकट्रेस को डिबग में डाल दिया, लेकिन अपवाद को ठीक से संभालने के लिए कभी वापस नहीं आया

अंतिम बिंदु कम से कम होने की संभावना है। मैं यह कहता हूं क्योंकि मुझे नहीं लगता कि कोई भी वास्तव में इस तरह से डिबग करता है। डिबगर के साथ कोड के माध्यम से कदम रखना डिबग करने का एक बहुत आसान तरीका है।

एक पकड़ ब्लॉक में क्या किया जाना चाहिए का सबसे अच्छा विवरण जोशुआ बलोच द्वारा प्रभावी जावा के अध्याय 9 में पाया जा सकता है ।

Question 12

C # में सभी अपवाद रनटाइम अपवाद हैं, लेकिन जावा में आपके पास रनटाइम अपवाद और चेक किए गए अपवाद हैं, जिन्हें आपको या तो पकड़ना है, या अपने तरीकों को घोषित करना है। यदि आप किसी ऐसी विधि को कहते हैं जिसमें अंत में "थ्रो" होता है, तो आपको या तो वहाँ उल्लिखित अपवादों को पकड़ना होगा, या आपकी विधि को उन अपवादों को भी घोषित करना होगा।

जावा लेख आमतौर पर केवल स्टैक ट्रेस को प्रिंट करते हैं या एक टिप्पणी करते हैं क्योंकि अपवाद हैंडलिंग लेख के विषय के मामले में अप्रासंगिक है। हालांकि परियोजनाओं में, अपवाद के प्रकार के आधार पर, इसके बारे में कुछ किया जाना चाहिए।

Question 13

आपको यह बहुत बार देखना चाहिए अगर प्रोग्रामर अपना काम सही करता है। अपवाद को अनदेखा करना एक बुरा, बुरा अभ्यास है! लेकिन कुछ कारण हैं कि कुछ ऐसा कर सकते हैं और अधिक समाधान कर सकते हैं:

"यह नहीं होगा!" निश्चित रूप से, कभी-कभी आप "जानते" हैं कि यह अपवाद नहीं होगा, लेकिन इसकी अभी भी अधिक संभावना है कि इसे अनदेखा करने के बजाय "कारण" के रूप में प्रस्तुत अपवाद को पुनर्विचार अपवाद के रूप में फिर से उखाड़ फेंके। मुझे यकीन है कि यह भविष्य में कुछ समय के लिए होगा। ;-)
प्रोटोटाइपिंग कोड यदि आप अपना सामान नीचे रख रहे हैं, तो यह देखने के लिए कि क्या यह काम करता है, आप उन सभी अपवादों को अनदेखा करना चाहते हैं जो हो सकते हैं। यह एकमात्र मामला है जो मैं कुछ आलसी (थ्रोएबल) पकड़ता हूं। लेकिन अगर कोड कुछ उपयोगी में बदल जाएगा, तो मैं उचित अपवाद हैंडलिंग शामिल करता हूं।
"मुझे नहीं पता क्या करना है!" मैंने बहुत कोड देखा, विशेष रूप से पुस्तकालय कोड, जो अपवादों को देखते हुए निगलता है क्योंकि आवेदन की इस परत में कोई उचित हैंडलिंग नहीं की जा सकती है। यह मत करो! बस अपवाद को हटा दें (या तो विधि हस्ताक्षर में एक थ्रो क्लॉज जोड़कर या अपवाद को लाइब्रेरी विशिष्ट में लपेटकर)।

Question 14

आपको हमेशा इसे वास्तविक दुनिया के संदर्भ में उपयुक्त रूप से आगे बढ़ाना चाहिए। बहुत सारे लेख और ट्यूटोरियल अपने कोड को अधिक महत्वपूर्ण बिंदुओं को प्राप्त करने के लिए सरल बनाएंगे, हालांकि सरल बनाने के लिए सबसे आसान चीजों में से एक त्रुटि-हैंडलिंग है (जब तक आप जो कर रहे हैं वह त्रुटि-हैंडलिंग पर एक लेख लिख रहा है :))। जैसे ही java code अपवाद से निपटने के लिए जाँच करेगा, तब एक साधारण साइलेंट (या लॉगिंग स्टेटमेंट) कैच ब्लॉक पर काम करना उदाहरण देने के लिए सबसे सरल तरीका है।

यदि आपको यह उदाहरण कोड के अलावा किसी और चीज में मिलता है, तो कोड को TDWTF पर अग्रेषित करने के लिए स्वतंत्र महसूस करें, हालाँकि उनके पास अब तक इसके कई उदाहरण हो सकते हैं :)

Question 15

मुझे डर है कि अधिकांश जावा प्रोग्रामर को यह नहीं पता है कि अपवाद के साथ क्या करना है, और हमेशा इसे एक झुंझलाहट के रूप में माना जाता है जो "नाममात्र" मामले के अपने कोडिंग को धीमा कर देता है। बेशक वे पूरी तरह से गलत हैं, लेकिन उन्हें यह समझाना मुश्किल है कि अपवादों से सही ढंग से निपटने के लिए आईटी महत्वपूर्ण है। जब भी मैं इस तरह के एक प्रोग्रामर का सामना करता हूं (यह अक्सर होता है) मैं उसे दो रीडिंग प्रविष्टियां देता हूं:

जावा में प्रसिद्ध सोच
यहाँ उपलब्ध बैरी रुज़क का एक छोटा और दिलचस्प लेख: www.oracle.com/technology/pub/articles/dev2arch/2006/11/effective-exception.html

वैसे, मैं दृढ़ता से सहमत हूं कि यह एक टाइप करने के लिए एक अपवाद को पकड़ने के लिए मूर्खतापूर्ण है, इसे एक रनटाइम एक्सेप्शन में एम्बेड किया गया है:

यदि आप इसे पकड़ते हैं, तो इसे संभालें।
अन्यथा, संभव अपवादों को जोड़ने के लिए अपने तरीके के हस्ताक्षर बदलें, जिसे आप संभाल नहीं पाएंगे / कर पाएंगे, इसलिए आपके कॉलर के पास इसे स्वयं करने का मौका होगा।

Question 16

चेक किए गए अपवादों और इंटरफेस के संयोजन से स्थिति उत्पन्न होती है कि कोड को उन एक्सॉसेस को संभालना चाहिए जो कभी भी फेंके नहीं जाते हैं। (यह भी सामान्य वंशानुक्रम पर लागू होता है, लेकिन यह इंटरफेस के साथ व्याख्या करने के लिए अधिक सामान्य और आसान है)

कारण: इंटरफ़ेस के विनिर्देशन में परिभाषित किए गए अपवादों के अलावा एक इंटरफ़ेस का कार्यान्वयन फेंक (चेक किया गया) अपवाद नहीं हो सकता है। इस कारण से, इंटरफ़ेस के रचनाकारों को यह नहीं पता होता है कि इंटरफ़ेस को लागू करने वाले वर्ग के कौन से तरीके वास्तव में अपवाद को फेंकने की आवश्यकता हो सकती है, यह निर्दिष्ट कर सकते हैं कि सभी विधियाँ कम से कम एक प्रकार के अपवाद को फेंक सकती हैं। उदाहरण: JDBC, जहां सब कुछ और उसकी दादी को SQLException फेंकने के लिए घोषित किया गया है।

लेकिन वास्तव में, वास्तविक कार्यान्वयन के कई तरीके बस विफल नहीं हो सकते हैं, इसलिए किसी भी परिस्थिति में वे कभी भी अपवाद नहीं फेंकते हैं। इस तरीके को कॉल करने वाले कोड को अभी भी किसी तरह अपवाद को "हैंडल" करना होगा, और सबसे आसान तरीका यह है कि अपवाद को निगल लें। कोई भी अपने कोड को अव्यवस्थित त्रुटि-हैंडलिंग के साथ अव्यवस्थित नहीं करना चाहता है जो कभी भी निष्पादित नहीं होता है।

Question 17

जैसा कि बताया गया है, प्रिंटस्टैकट्रेस () को कॉल करना वास्तव में साइलेंट हैंडलिंग नहीं है।

अपवाद के इस प्रकार "निगलने" का कारण यह है कि, यदि आप अपवाद को श्रृंखला में पास करते हैं, तो आपको अभी भी अपवाद को संभालना होगा या एप्लिकेशन को क्रैश होने देना होगा। इसलिए, इसे उस स्तर पर संभालना, जो सूचना डंप के साथ होता है, शीर्ष स्तर पर सूचना डंप के साथ इसे हैंडल करने से कोई भी बदतर नहीं है।

Question 18

इसका आलसी अभ्यास - वास्तव में इससे कम नहीं।

यह आमतौर पर तब किया जाता है जब आप वास्तव में अपवाद के बारे में परवाह नहीं करते हैं - बजाय अपनी उंगली के काम को बढ़ाने के।

Question 19

मैं असहमत हूं कि एक जाँच किए गए अपवाद को फिर से पढ़ना एक बेहतर विचार है। पकड़ने का अर्थ है संभालना; यदि आपको पुनर्जन्म करना है, तो आपको नहीं पकड़ना चाहिए। मैं उस मामले में विधि हस्ताक्षर के लिए थ्रो क्लॉज़ जोड़ूंगा।

मैं कहूंगा कि अनियंत्रित एक में एक अपवाद को लपेटना (उदाहरण के लिए, जिस तरह से वसंत ने जाँच किए गए SQLException को उसकी अनियंत्रित पदानुक्रम की एक आवृत्ति में लपेटा) स्वीकार्य है।

लॉगिंग को हैंडलिंग माना जा सकता है। यदि कंसोल में लिखने के बजाय log4j का उपयोग करके स्टैक ट्रेस लॉग करने के लिए उदाहरण को बदल दिया गया था, तो क्या यह स्वीकार्य होगा? ज्यादा बदलाव नहीं, आई.एम.ओ.

वास्तविक मुद्दा यह है कि असाधारण और एक स्वीकार्य पुनर्प्राप्ति प्रक्रिया माना जाता है। यदि आप अपवाद से उबर नहीं पाते हैं, तो सबसे अच्छा आप विफलता की रिपोर्ट कर सकते हैं।

Question 20

कृपया कभी भी, कभी भी, कभी भी अनियंत्रित अपवाद में चेक किए गए अपवाद को न लपेटें।

यदि आप अपने आप को अपवादों से निपटते हुए पाते हैं, तो आपको नहीं लगता कि आपको चाहिए तो मेरी सलाह है कि आप शायद अमूर्त के गलत स्तर पर काम कर रहे हैं।

मैं विस्तृत हूँ: जाँच की और अनियंत्रित अपवाद दो बहुत अलग जानवर हैं। चेक किए गए अपवाद, त्रुटि कोड वापस करने की पुरानी पद्धति के समान हैं ... हाँ, वे त्रुटि कोड की तुलना में संभाल करने के लिए कुछ अधिक दर्दनाक हैं, लेकिन उनके फायदे भी हैं। अनियंत्रित अपवाद प्रोग्रामिंग त्रुटियां और महत्वपूर्ण प्रणाली विफलताएं हैं ... दूसरे शब्दों में असाधारण अपवाद। जब यह समझाने की कोशिश की जा रही है कि अपवाद क्या है तो बहुत से लोग पूरी तरह गड़बड़ हो जाते हैं क्योंकि वे इन दोनों में अंतर को स्वीकार नहीं करते हैं, बहुत अलग, मामले।

Question 21

क्योंकि उन्होंने अभी तक यह तरकीब नहीं सीखी है:

class ExceptionUtils {
    public static RuntimeException cloak(Throwable t) {
        return ExceptionUtils.<RuntimeException>castAndRethrow(t);
    }

    @SuppressWarnings("unchecked")
    private static <X extends Throwable> X castAndRethrow(Throwable t) throws X {
        throw (X) t;
    }
}

class Main {
    public static void main(String[] args) { // Note no "throws" declaration
        try {
            // Do stuff that can throw IOException
        } catch (IOException ex) {
            // Pretend to throw RuntimeException, but really rethrowing the IOException
            throw ExceptionUtils.cloak(ex);
        }
    }
}

Question 22

अपवादों का वास्तविक बिंदु त्रुटि हैंडलिंग को आसान बनाना और त्रुटि का पता लगाने से अलग करना है। यह त्रुटि कोड द्वारा त्रुटियों का प्रतिनिधित्व करने के विपरीत है, जहां त्रुटि हैंडलिंग कोड हर जगह बिखरा हुआ है और हर कॉल जो विफल हो सकती है, रिटर्न कोड के लिए जाँच की जाएगी।

यदि अपवाद एक त्रुटि का प्रतिनिधित्व करता है (जो अधिकांश मामलों में है) आमतौर पर इसे संभालने के लिए सबसे उचित तरीका है कि किसी ऊपरी परत को संभालना और छोड़ देना। अलग-अलग अपवाद को रोककर विचार किया जाना चाहिए यदि इसमें कुछ सार्थक शब्दार्थ जोड़े जाते हैं, अर्थात यह त्रुटि एक असामान्य प्रणाली विफलता / अस्थायी (नेटवर्किंग) समस्या है / यह क्लाइंट या सर्वर साइड त्रुटि आदि है।

सभी त्रुटि से निपटने की रणनीतियों में सबसे अनभिज्ञ व्यक्ति त्रुटि संदेश छिपा रहा है या आगे बढ़ रहा है और कुछ भी नहीं हुआ है।

सन लोग चाहते थे कि कोड अधिक स्पष्ट और मजबूर प्रोग्रामर हो, जो यह लिखें कि अपवाद किस विधि से फेंका जा सकता है। यह सही कदम लग रहा था - किसी को भी पता चल जाएगा कि किसी भी विधि कॉल के बदले में क्या उम्मीद की जाती है, यह प्रोटोटाइप है (यह इस प्रकार का मान लौटा सकता है या निर्दिष्ट वर्गों में से एक का उदाहरण फेंक सकता है (या यह उपवर्ग है)।

लेकिन जैसा कि बहुत से अज्ञानी जावा प्रोग्रामर के साथ हुआ, वे अब अपवाद से निपटने का व्यवहार करते हैं जैसे कि यह एक भाषा बग / "फीचर" था जिसे वर्कअराउंड की जरूरत थी और सबसे खराब या लगभग संभव तरीके से कोड लिखना था:

त्रुटि के संदर्भ में तुरंत संभाला जाता है जो यह तय करने के लिए उपयुक्त नहीं है कि इसके साथ क्या करना है।
इसे चुपचाप प्रदर्शित या अनदेखा किया जाता है और कंप्यूटिंग तब भी जारी रहती है जब आगे कोड को ठीक से चलाने का कोई मौका नहीं मिलता है।
विधि का कॉलर अंतर नहीं कर सकता है कि यह सफलतापूर्वक समाप्त हुआ या नहीं।

से "सही तरीका" कैसे लिखें?

अपवाद के प्रत्येक आधार वर्ग को इंगित करें जिसे विधि हेडर में फेंका जा सकता है। AFAICR ग्रहण इसे स्वचालित रूप से कर सकता है।
विधि प्रोटोटाइप में फेंक सूची को सार्थक बनाएं। लंबी सूची व्यर्थ है और "थ्रो एक्ससेप्शन" आलसी है (लेकिन उपयोगी है जब आप अपवादों के बारे में ज्यादा परेशान नहीं करते हैं)।
जब "गलत तरीका" सरल "थ्रो एक्ससेप्शन" लिखना बहुत बेहतर होता है और "कोशिश {...} कैच (अपवाद ई) {e.printStackTrace ();}" की तुलना में कम बाइट लेता है।
जरूरत पड़ने पर रेथ्रो ने जंजीर का अपवाद किया।

Question 23

यदि आप चाहते हैं कि आपका अपवाद वर्तमान पद्धति के दायरे से बाहर हो जाए, तो आपको इसे वास्तव में पकड़ने की आवश्यकता नहीं है, इसके बजाय आप विधि हस्ताक्षर में 'थ्रो' स्टेटमेंट जोड़ते हैं।

आपके द्वारा देखे गए प्रयास / कैच स्टेटमेंट केवल उस कोड में हैं जहां प्रोग्रामर ने स्पष्ट रूप से अपवाद को संभालने का फैसला किया है और इसलिए इसे आगे नहीं फेंकना है।

Question 24

मुझे लगता है कि डेवलपर्स किसी विशेष संदर्भ में "सही काम करने" के महत्व पर विचार करने का भी प्रयास करते हैं। अक्सर कोड को फेंकने के लिए या जब अपवाद को ऊपर की ओर प्रचारित किया जाता है तो वह कुछ भी नहीं खरीदेगा क्योंकि अपवाद घातक है, आप "गलत काम" करके समय और प्रयास बचा सकते हैं।

Question 25

जब आप इससे उबर नहीं पाते हैं तो आप आमतौर पर एक अपवाद को निगल लेंगे लेकिन यह महत्वपूर्ण नहीं है। एक अच्छा उदाहरण IOExcetion है जिसे डेटाबेस कनेक्शन को बंद करते समय फेंक दिया जा सकता है। क्या आप वास्तव में दुर्घटना चाहते हैं अगर ऐसा होता है? यही कारण है कि जकार्ता के DBUtils में करीब-करीब तरीके हैं।

अब चेक किए गए अपवाद के लिए जिसे आप पुनर्प्राप्त नहीं कर सकते हैं, लेकिन महत्वपूर्ण हैं (आमतौर पर प्रोग्रामिंग त्रुटियों के कारण), उन्हें निगल नहीं। मुझे लगता है कि अपवाद को समस्या के स्रोत के लिए निकटतम रूप से लॉग किया जाना चाहिए, इसलिए मैं प्रिंटस्टैकट्रेस () कॉल को हटाने की सिफारिश नहीं करूंगा। आप इन अपवादों को आपके व्यवसाय विधि में घोषित नहीं करने के एकमात्र उद्देश्य के लिए इन्हें RuntimeException में बदलना चाहेंगे। वास्तव में यह उच्च स्तरीय व्यावसायिक विधियों जैसे कि CreateClientAccount () थ्रोइंग प्रोग्रामिंगइग्रेशन अपवाद (SQLException) को पढ़ने के लिए समझ में नहीं आता है, यदि आप अपने sql में टाइपो या खराब इंडेक्स एक्सेस कर रहे हैं तो कुछ भी नहीं कर सकते हैं।

Question 26

अनुभव से, एक अपवाद को निगलना ज्यादातर हानिकारक है जब यह मुद्रित नहीं होता है। यह ध्यान देने में मदद करता है कि क्या आप दुर्घटनाग्रस्त हो गए हैं, और मैं ऐसा जानबूझकर कई बार करूंगा, लेकिन केवल अपवाद को प्रिंट करना और जारी रखना आपको समस्या को खोजने और उसे ठीक करने की अनुमति देता है, और फिर भी आमतौर पर उसी कोडबेस पर काम करने वाले दूसरों को नकारात्मक रूप से प्रभावित नहीं करता है। ।

मैं वास्तव में फेल-फास्ट / फेल-हार्ड में हूं, लेकिन कम से कम इसका प्रिंट आउट ले सकता हूं। यदि आप वास्तव में एक अपवाद "खाएं" (जो वास्तव में कुछ नहीं करना है: {}) तो इसे खोजने के लिए किसी व्यक्ति को खर्च करना होगा।

समस्या यह है कि जावा आपको बहुत सारे सामानों को पकड़ने के लिए मजबूर करता है जो डेवलपर जानता है कि उन्हें फेंक नहीं दिया जाएगा, या यदि वे हैं तो परवाह नहीं करता है। सबसे आम थ्रेड है। स्लीप ()। मुझे लगता है कि ऐसे छेद हैं जो यहां मुद्दों को फैलाने की अनुमति दे सकते हैं, लेकिन आम तौर पर आप जानते हैं कि आप इसे बाधित नहीं कर रहे हैं। अवधि।

Question 27

ऐसे कई कारण हो सकते हैं कि कोई व्यक्ति अपवाद का उपयोग क्यों करेगा। कई मामलों में यह एक बुरा विचार है क्योंकि आप RuntimeException को भी पकड़ते हैं - और अच्छी तरह से आप यह नहीं जानते हैं कि ऐसा होने के बाद अंतर्निहित वस्तुएं किस स्थिति में होंगी? अप्रत्याशित परिस्थितियों के साथ यह हमेशा कठिन बात है: क्या आप भरोसा कर सकते हैं कि बाकी कोड बाद में विफल नहीं होंगे।

आपका उदाहरण स्टैकट्रेस को प्रिंट करता है ताकि कम से कम आपको पता चल जाए कि मूल कारण क्या हो सकता है। बड़े सॉफ्टवेयर प्रोजेक्ट्स में इन चीजों को लॉग करना बेहतर आइडिया है। और उम्मीद करते हैं कि लॉग घटक अपवादों को नहीं फेंकता है या तो हमारे आप एक अनंत लूप में समाप्त हो सकते हैं (जो शायद आपके जेवीएम को मार देगा)।

Question 28

यदि आपके पास एक अपवाद है और आप इसे एक विधि में संभालना नहीं चाहते हैं, तो आपको केवल विधि को अपवाद फेंकना चाहिए। केवल अपवादों को पकड़ें और संभालें यदि आप इसके साथ कुछ उपयोगी करने जा रहे हैं। बस इसे लॉग करना मेरी पुस्तक में बहुत उपयोगी नहीं है क्योंकि उपयोगकर्ताओं के पास अपवादों की तलाश में लॉग पढ़ने के लिए शायद ही कभी समय होता है या यदि अपवाद को फेंक दिया जाए तो क्या करना चाहिए।

अपवाद को लपेटते समय एक विकल्प है, मैं आपको ऐसा करने का सुझाव नहीं दूंगा जब तक कि ऐसा न हो; आप मौजूद इंटरफ़ेस से मिलान करने के लिए एक अलग अपवाद फेंक रहे हैं या वास्तव में ऐसा कोई तरीका नहीं है कि इस तरह के अपवाद को फेंक दिया जाना चाहिए।

BTW: यदि आप एक चेक किए गए अपवाद को फिर से फेंकना चाहते हैं तो आप इसके साथ ऐसा कर सकते हैं

try {
   // do something
} catch (Throwable e) {
   // do something with the exception
   Thread.currentThread().stop(e); // doesn't actually stop the current thread, but throws the exception/error/throwable
}

नोट: यदि आप ऐसा करते हैं, तो आपको यह सुनिश्चित करना चाहिए कि विधि के लिए फेंकता घोषणा सही है क्योंकि कंपाइलर इस स्थिति में आपके लिए ऐसा करने में असमर्थ है।

Question 29

क्योंकि यह एक सर्वोत्तम अभ्यास है। मुझे लगा कि हर कोई जानता है।
लेकिन ठंडी सच्चाई यह है कि कोई भी वास्तव में यह नहीं समझता है कि अपवादों के साथ कैसे काम किया जाए। सी त्रुटि सौंपने की शैली ने इतना अधिक अर्थ दिया।