एक चेक अपवाद बनाना एक RuntimeException

Question

मैं एक विरासत प्रणाली पर काम कर रहा हूं जिसमें एक कस्टम अपवाद है जिसका उपयोग हर जगह-भौतिकता है। यह ServletException वर्ग से प्रेरित था, जिसमें कहा गया था "अच्छी तरह से जब भी आप अपने सर्वलेट में अपवाद रखते हैं, तो आप इसे ServletException फेंकना चाहेंगे"।

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

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

मेरा प्रश्न है ... एक बार चेक अपवाद लेने और इसे रनटाइम अपवाद बनाने के दुष्प्रभाव क्या हैं?

मैं अनावश्यक जांच करने के लिए चेतावनी से अलग किसी भी के बारे में सोच नहीं कर सकते, और घोषणाओं फेंकता है, लेकिन यह कोई है जो इस सड़क के नीचे से पहले किया गया है से इनपुट प्राप्त करने के लिए अच्छा होगा।

Answer 1

एक अनचेक किए गए चेक में अपवाद को बदलना मौजूदा, काम करने वाले कोड पर बहुत कम व्यावहारिक प्रभाव डालता है, लेकिन आपको संभावना है कि आपके कोड में कहीं कहीं catch (RuntimeException ...) पर यह देखने की आवश्यकता है। इस तरह के कैच अब आपके कस्टम अपवाद को अवरुद्ध नहीं करते हैं, लेकिन अगर आप इसे अनचेक करते हैं तो वे करेंगे।

यदि आप उस अपवाद को फेंकने वाले तरीकों से संबंधित कुछ भी प्रतिबिंबित करते हैं तो आप मुद्दों में भी भाग ले सकते हैं (जो स्पष्ट रूप से उनमें से अधिकतर है)।

Answer 2

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

उदाहरण के लिए, हम गहरी परतों में इस तरह कोड का एक टन था:

catch(IOException e){  
    Throwables.propagate(e); 
} 

हम लापरवाही से यह सब परत के ऊपर है कि पैटर्न का इस्तेमाल किया और, जब हम अपवाद कारण की जाँच करने की जरूरत है, हम हमेशा के लिए किया था अपवाद का कारण प्राप्त करने के लिए और उच्च परतों में बहुत सारे बॉयलरप्लेट बनाए। इस दिन तक मेरा मानना ​​है कि ग्रैन्युलरिटी को संरक्षित करने के लिए गैर-जांच अपवादों का एक अच्छा वर्ग पदानुक्रम बनाना बेहतर है। जैसे

catch(IOException e){ 
    throw new FileNotCreatedException(e); 
} 

और इस के साथ आप अन्य परतों में आसानी से अपवाद को पकड़ने और त्रुटियों और फ़ॉलबैक आसानी से विभाजित कर सकते हैं:

catch(FileNotCreatedException e){ 
    notifyError(e); 
} catch(NoMoreStorageException e){ 
    releaseSomeStorage(); 
    retryOperation(); 
} 

Answer 3

यहाँ कुछ है कि मैं

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

मेरी राय में एक सामान्य नियम के रूप में अंगूठे:

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