कक्षाएं अपवाद प्रबंधित करने के लिए उपयोग की जाती हैं

Question

क्या अपवादों को पकड़ने के लिए उपयोग की जाने वाली छोटी विधियों वाले वर्ग के लिए अच्छा है?

class ContractUtils{ 
    public static String getCode(Contract contract) throws MyException{ 
    try{ 
     return contract.getInfo().getCode(); //throws ContractException and LogicException 
    }catch(Exception e){ 
     throw new MyException("error during code reading:"+e.getMessage, e); 
    } 
    } 
    //other methods like above... 
} 

Answer 1

आपका उपयोगिता वर्ग ContractUtilअविवेक का एक स्तर सिर्फ एक और अपवाद में मूल अपवाद अनुवाद करने के लिए परिचय:

प्रत्यक्ष कॉल करने के बजाय

:

return contract.getInfo().getCode() 

आप अब कृत्रिम अधिक लिख रहे हैं

return ContractUtils.getCode(contract); 

लेकिन स्थितियों में, जहां इस समाधान जायज हो सकता है, उदा .:

आप ContractException या LogicException फेंकने के लिए अनुमति नहीं है वहाँ हो सकता है, और यदि आप इस विधि समय की एक बहुत बुला रहे हैं।

लेकिन यदि आप इसके हस्ताक्षर को बदल सकते हैं तो यह केवल MyException फेंकने के लिए मूल विधि को फिर से डिजाइन करना बेहतर होगा।

Answer 2

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

प्रबंध अपवाद में सर्वोत्तम प्रथाओं के लिए इस लिंक का संदर्भ लें: एक कस्टम अपवाद बुला कोड को अतिरिक्त संदर्भ या मूल्य प्रदान करता है

https://softwareengineering.stackexchange.com/questions/209693/best-practices-to-create-error-codes-pattern-for-an-enterprise-project-in-c

Answer 3

हैं, तो यह उपयोगी है और उन्हें तैयार करने के लिए प्रोत्साहित किया।

स्थिर विधियों का उपयोग करने के लिए आप दृष्टिकोण पूरी तरह से स्वीकार्य हैं। यहां एक अच्छा SO answer छोटा स्थैतिक तरीकों के लिए उपयोग के मामलों को परिभाषित करना है।

Answer 4

पठनीयता के लिए त्रुटि प्रबंधन से एप्लिकेशन तर्क को अलग करने के लिए उपयोगी हो सकता है।

लेकिन उपयोगिता वर्ग में नहीं, क्योंकि आप इसका उपयोग करना भूल सकते हैं, और अपना कार्य सीधे पूरा कर सकते हैं और फिर भी एक कस्टम अपवाद की उम्मीद कर सकते हैं। मैं इस तर्क को संपर्क कक्षा में रखूंगा यदि इसका उपयोग अक्सर पर्याप्त होता है (और contract.getInfo() निजी बनाएं)। एक और नकारात्मक बात यह है कि इससे अन्य वर्गों के कार्यान्वयन विवरण, संभावित रूप से तोड़ने और उच्च निर्भरता के कारण उन्हें कम रखरखाव करने के बारे में उपयोगिता वर्गों को बहुत जानकार (LoD - https://en.wikipedia.org/wiki/Law_of_Demeter) हो सकता है।

और, आप विशिष्ट अपवादों को पकड़ना चाह सकते हैं।