क्या त्रुटियों को जल्दी "पकड़ने" के उपकरण के रूप में अपवादों का उपयोग करना ठीक है?

Question

मैं समस्याओं को जल्द पकड़ने के लिए अपवादों का उपयोग करता हूं। उदाहरण के लिए:

public int getAverageAge(Person p1, Person p2){
    if(p1 == null || p2 == null)
        throw new IllegalArgumentException("One or more of input persons is null").
    return (p1.getAge() + p2.getAge()) / 2;
}

मेरा कार्यक्रम nullइस समारोह में कभी नहीं होना चाहिए । मैंने इसे कभी इरादा नहीं किया। हालाँकि जैसा कि हम सभी जानते हैं, अनजाने सामान प्रोग्रामिंग में होता है।

यदि यह समस्या होती है, तो एक अपवाद को फेंकने से मुझे इससे पहले कि यह कार्यक्रम में अन्य स्थानों पर और अधिक समस्याओं का कारण बनता है, इसे ठीक करने और इसे ठीक करने की अनुमति मिलती है। अपवाद कार्यक्रम को रोकता है और मुझे बताता है "खराब सामान यहां हुआ, इसे ठीक करें"। इसके बजाय nullकार्यक्रम के इर्द-गिर्द घूमने से समस्याएँ कहीं और बढ़ जाती हैं।

अब, आप ठीक कह रहे हैं, इस मामले में nullबस एक NullPointerExceptionसही दूर का कारण होगा , इसलिए यह सबसे अच्छा उदाहरण नहीं हो सकता है।

लेकिन इस तरह के उदाहरण के लिए एक विधि पर विचार करें:

public void registerPerson(Person person){
    persons.add(person);
    notifyRegisterObservers(person); // sends the person object to all kinds of objects.
}

इस मामले में, एक nullपैरामीटर को प्रोग्राम के आसपास पारित किया जाएगा, और बहुत बाद में त्रुटियां हो सकती हैं, जो उनके मूल में वापस ट्रेस करना मुश्किल होगा।

फ़ंक्शन को इस तरह बदलना:

public void registerPerson(Person person){
    if(person == null) throw new IllegalArgumentException("Input person is null.");
    persons.add(person);
    notifyRegisterObservers(person); // sends the person object to all kinds of objects.
}

इससे पहले कि मैं अन्य स्थानों पर अजीब त्रुटियों का कारण बनता हूं, मुझे समस्या को हल करने की अनुमति दें।

इसके अलावा, एक nullपैरामीटर के रूप में एक संदर्भ केवल एक उदाहरण है। अमान्य तर्कों से लेकर किसी भी चीज़ में कई तरह की समस्याएं हो सकती हैं। हमेशा उन्हें जल्दी स्पॉट करना बेहतर होता है।

---

तो मेरा सवाल बस यह है: क्या यह अच्छा अभ्यास है? समस्या निवारण उपकरण के रूप में अपवादों का मेरा उपयोग अच्छा है? क्या यह अपवादों का एक वैध अनुप्रयोग है या यह समस्याग्रस्त है?

Comments

क्या डाउनवॉटर समझा सकता है कि इस प्रश्न में क्या गलत है?

— जियोर्जियो

"दुर्घटना जल्दी, अक्सर दुर्घटना"

— ब्रायन चेन

यह वस्तुतः क्या अपवाद हैं।

— raptortech97 12

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

— ब्रायन

चूंकि आप IllegalArgumentException को फेंक रहे हैं, इसलिए इसे " इनपुट व्यक्ति" कहना बेमानी है ।

— केविन क्लाइन

Answer 1

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

Comments

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

— माइकल शोपिन

इसे "विफल उपवास" के रूप में भी जाना जाता है

— keuleJ

Answer 2

हां, अपवादों को फेंकना एक अच्छा विचार है। उन्हें जल्दी फेंक दो, उन्हें अक्सर फेंक दो, उन्हें उत्सुकता से फेंक दो।

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

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

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

एक सुधार जो मैंने पाया है वह केवल आधार-स्तर के अपवादों को नहीं फेंकना है। IllegalArgumentExceptionअच्छा है, लेकिन यह अनिवार्य रूप से कहीं से भी आ सकता है। अधिकांश भाषाओं में कस्टम अपवाद जोड़ने में बहुत अधिक समय नहीं लगता है। अपने व्यक्ति-हैंडलिंग मॉड्यूल के लिए, कहें:

public class PersonArgumentException extends IllegalArgumentException {
    public MyException(String message) {
        super(message);
    }
}

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

Comments

I've never actually met an application codebase for which I'd want (most) checks removed at runtime. फिर आपने वह कोड नहीं किया है जो प्रदर्शन-महत्वपूर्ण है। मैं अभी कुछ ऐसा काम कर रहा हूं जिसमें 37M ऑप्‍शन प्रति सेकंड संकलित है और उनके बिना 42M। कथनों में बाहरी इनपुट मान्य नहीं हैं, वे यह सुनिश्चित करने के लिए वहां मौजूद हैं कि कोड सही है। मेरे ग्राहक एक बार संतुष्ट होने के बाद 13% वृद्धि से अधिक खुश हैं कि मेरा सामान टूटा नहीं है।

— ब्लरफेल

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

— सेलाली अडोबोर

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

— सेलाली अडोबोर

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

— जोनाथन यूनिस

मैंने संख्यात्मक / एचपीसी और ओएस / मिडलवेयर स्थानों में प्रदर्शन-संवेदनशील काम किया है। एक 13% प्रदर्शन टक्कर कोई छोटी बात नहीं है। मैं इसे प्राप्त करने के लिए कुछ चेक बंद कर सकता हूं, उसी तरह एक सैन्य कमांडर 105% नाममात्र रिएक्टर आउटपुट के लिए पूछ सकता है। लेकिन मैंने अक्सर चेक, बैकअप और अन्य सुरक्षा को बंद करने के लिए एक कारण के रूप में दिया "यह इस तरह से तेजी से चलेगा" देखा है। यह मूल रूप से अतिरिक्त प्रदर्शन के लिए लचीलापन और सुरक्षा (डेटा अखंडता सहित कई मामलों में) बंद कर रहा है। क्या यह सार्थक है एक निर्णय कॉल है।

— जोनाथन यूनिस

Answer 3

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

तो हाँ, रक्षात्मक प्रोग्रामिंग जल्दी से बग का पता लगाने और ठीक करने के लिए एक प्रभावी तरीका है। दूसरी ओर, इसे ओवरडोन किया जा सकता है, विशेषकर अशक्त संदर्भों के साथ।

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

अधिक यथार्थवादी उदाहरण के लिए, आप assertबयानों का उपयोग कर सकते हैं , जो:

1. लिखने और पढ़ने के लिए छोटे हैं:

       assert p1 : "p1 is null";
       assert p2 : "p2 is null";
   

2. विशेष रूप से आपके दृष्टिकोण के लिए डिज़ाइन किए गए हैं। एक ऐसी दुनिया में जहाँ आपके दावे और अपवाद दोनों हैं, आप उन्हें निम्न प्रकार से अलग कर सकते हैं:

   • प्रोग्रामिंग त्रुटियों के लिए दावे हैं ("/ * यह कभी नहीं होना चाहिए * /"),
   • अपवाद के लिए कर रहे हैं कोने मामलों (असाधारण लेकिन संभावित स्थितियों)

इस प्रकार, मुखरता के साथ अपने आवेदन के आदानों और / या राज्य के बारे में अपनी मान्यताओं को उजागर करने से अगले डेवलपर को आपके कोड के उद्देश्य को थोड़ा और समझने में मदद मिलती है।

एक स्थैतिक विश्लेषक (जैसे संकलक) और भी खुश हो सकता है।

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

Answer 4

जहाँ तक मुझे पता है अलग-अलग प्रोग्रामर एक समाधान या दूसरे को पसंद करते हैं।

पहला समाधान आमतौर पर पसंद किया जाता है क्योंकि यह अधिक संक्षिप्त है, विशेष रूप से, आपको अलग-अलग कार्यों में एक ही स्थिति को बार-बार जांचने की आवश्यकता नहीं है।

मैं दूसरा समाधान खोजता हूं, जैसे

public void registerPerson(Person person){
    if(person == null) throw new IllegalArgumentException("Input person is null.");
    persons.add(person);
    notifyRegisterObservers(person); // sends the person object to all kinds of objects.
}

अधिक ठोस, क्योंकि

1. यह जितनी जल्दी हो सके त्रुटि को पकड़ लेता है, अर्थात जब registerPerson()कॉल किया जाता है, न कि जब एक शून्य पॉइंटर अपवाद को कॉल स्टैक के नीचे कहीं फेंक दिया जाता है। डीबग करना बहुत आसान हो जाता है: हम सभी जानते हैं कि एक बग के रूप में खुद को प्रकट करने से पहले एक अमान्य मूल्य कोड से कितनी दूर तक यात्रा कर सकता है।
2. यह फ़ंक्शंस के बीच युग्मन को घटाता है: ऐसी registerPerson()कोई भी धारणा नहीं बनाता है जिसके बारे में अन्य फ़ंक्शन personतर्क का उपयोग करके समाप्त हो जाएंगे और वे इसका उपयोग कैसे करेंगे: nullएक त्रुटि जो निर्णय लिया जाता है और स्थानीय रूप से लागू किया जाता है।

इसलिए, विशेष रूप से यदि कोड बल्कि जटिल है, तो मैं इस दूसरे दृष्टिकोण को प्राथमिकता देता हूं।

Comments

कारण देते हुए ("इनपुट व्यक्ति अशक्त है।") समस्या को समझने में मदद करता है, जब एक पुस्तकालय में कुछ अस्पष्ट विधि विफल होती है।

— फ्लोरियन एफ

Answer 5

सामान्य तौर पर, हाँ, "जल्दी असफल होना" एक अच्छा विचार है। हालाँकि, आपके विशिष्ट उदाहरण में, स्पष्ट IllegalArgumentExceptionएक पर एक महत्वपूर्ण सुधार प्रदान नहीं करता है NullReferenceException- क्योंकि दोनों ऑब्जेक्ट्स को पहले से ही फ़ंक्शन के तर्क के रूप में वितरित किया जाता है।

लेकिन थोड़ा अलग उदाहरण देखें।

class PersonCalculator {
    PersonCalculator(Person p) {
        if (p == null) throw new ArgumentNullException("p");
        _p = p;
    }

    void Calculate() {
        // Do something to p
    }
}

यदि कंस्ट्रक्टर में कोई तर्क जाँच नहीं था, तो आपको NullReferenceExceptionकॉल करने पर मिलेगाCalculate ।

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

हम चाहते हैं कि स्पष्ट तर्क के चेक निकालने हैं, तो आप यह पता लगाने की क्यों एक होगा NullReferenceExceptionउस समय हुआ जब Calculateबुलाया गया था। और इस बात पर नज़र रखना कि किसी nullव्यक्ति के साथ ऑब्जेक्ट का निर्माण क्यों किया गया था , मुश्किल हो सकता है, खासकर अगर कैलकुलेटर का निर्माण करने वाला कोड उस कोड के करीब नहीं है जो वास्तव में Calculateफ़ंक्शन को कॉल करता है।

Answer 6

आपके द्वारा दिए गए उदाहरणों में नहीं।

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

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

लेकिन सामान्य तौर पर, आपको यह निर्धारित करने से पहले जल्दी फेंक देना चाहिए कि कुछ गलत हो गया है (DRY का सम्मान करते हुए)। हालांकि ये उस के महान उदाहरण नहीं हैं।

Answer 7

आपके उदाहरण समारोह में, मैं पसंद करूंगा कि आपने कोई जांच नहीं की है और केवल अनुमति दें NullReferenceException होने दिया।

एक के लिए, यह वैसे भी वहाँ एक अशांति से गुजरने का कोई मतलब नहीं है, इसलिए मैं एक फेंकने के आधार पर समस्या का तुरंत पता लगाऊंगा NullReferenceException ।

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

आपके फ़ंक्शन में डिज़ाइन-टाइम त्रुटि की स्थिति में मदद करने के लिए आप वास्तव में कुछ भी नहीं कर सकते हैं, इसलिए बस विफलता को इसे बदलने के बिना होने दें।

Comments

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

— जियोर्जियो

"एक के लिए, यह वैसे भी वहाँ एक अशांति पारित करने के लिए कोई मतलब नहीं है, इसलिए मैं एक NullReferenceException के फेंकने के आधार पर समस्या का तुरंत पता लगाऊंगा।": जरूरी नहीं, जैसा कि प्रोग का दूसरा उदाहरण दिखाता है।

— जियोर्जियो

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

— जियोर्जियो

RuntimeException यही है। कोई भी शर्त जो "नहीं होनी चाहिए" लेकिन आपके कोड को काम करने से रोकती है उसे फेंक देना चाहिए। आपको उन्हें विधि हस्ताक्षर में घोषित करने की आवश्यकता नहीं है। लेकिन आपको उन्हें किसी बिंदु पर पकड़ने और रिपोर्ट करने की आवश्यकता है कि फ़ंक्शन अनुरोध अनुरोध क्रिया विफल हो गई।

— फ्लोरियन एफ

प्रश्न एक भाषा को निर्दिष्ट नहीं करता है, इसलिए उदाहरण के RuntimeExceptionलिए भरोसा करना एक मान्य धारणा नहीं है।