क्या कन्स्ट्रक्टर में अपवाद हैंडलिंग डालना अच्छा अभ्यास है?

Question

क्या क्लास कन्स्ट्रक्टर में अपवाद हैंडलिंग कोड होना वैध है, या इसे टालना चाहिए? क्या किसी को कन्स्ट्रक्टर में अपवाद-उत्पन्न कोड होने से बचना चाहिए?

Answer 1

हां, यह बिल्कुल उचित है।

class List { 
    public List(int length) { 
     if(length < 0) { 
      throw new ArgumentOutOfRangeException(
       "length", 
       "length can not be negative" 
      ); 
     } 
     // okay, go! 
    } 
} 

एक List नकारात्मक लंबाई के साथ सबसे निश्चित रूप से असाधारण है: और कैसे आप इस तरह एक परिस्थिति के लिए होगा। आप इसे कॉलर पर वापस जाने नहीं दे सकते हैं और उन्हें लगता है कि निर्माण सफल रहा है। विकल्प क्या है, CheckIfConstructionSucceeded इंस्टेंस सदस्य फ़ंक्शन? Yucky।

या

class FileParser { 
    public FileParser(string path) { 
     if(!File.Exists(path)) { 
      throw new FileNotFoundException(path); 
     } 
     // okay, go! 
    } 
} 

फिर के बारे में क्या है, यह एक फेंक है और कुछ नहीं स्वीकार्य है।

Answer 2

मान लिया जाये कि यह, सी ++ तुम्हारे बारे में बात कर रहे हैं अपवाद को ऊपर उठाने के लिए वास्तव में एक निर्माता में त्रुटियों का संकेत करने के लिए एक ही रास्ता है - तो यह निश्चित रूप से परहेज नहीं किया जाना चाहिए (*)

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

(*) जब तक आप पंथ कि सी में अपवाद से बचा जाता है ++

Answer 3

सी ++ में नहीं कर रहे हैं के रूप में, ctors सबसे अच्छा वापस ऊपर अपवाद फेंकने के लिए रखा जाता है। FAQ:17.2

Answer 4

मेरा मानना ​​है कि ऑब्जेक्ट के निर्माण को रोकने के लिए एक निर्माता में अपवाद फेंकना वैध है।

Answer 5

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

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

Answer 6

कहीं भी एक अपवाद फेंकने की संभावना है, "सर्वोत्तम अभ्यास" इसे संभालने, कन्स्ट्रक्टर या अन्यथा है।

यह निर्माता के लिए जटिलता का एक और परत जोड़ने, जब से तुम सही तरीके से प्रारंभ है, भले ही एक त्रुटि होती है सब कुछ सुनिश्चित करने के लिए है, लेकिन यह गाड़ी कोड :)

Answer 7

ज़रूर होने की तुलना में बेहतर है, असफल के रूप में जल्दी के रूप में आप ऐसा कर सकते हैं! रचनाकारों के अंदर इनपुट पैराम के कुछ सत्यापन गलत हो सकते हैं, इसलिए असंगत निर्मित डेटा के साथ आगे बढ़ने के बजाय, असफल होने के लिए यह निश्चित रूप से लायक है।

 

Constructor(Param param){ 
    if(param == null) 
    throw new IllegalArgumentException(...); 
}