क्या आपके कोड में दी गई चेतावनियों का उपयोग करना एक अच्छा अभ्यास है?

Question

मैं बिना किसी चेतावनी के कोड को संकलित करने के लिए अधिकतर @SuppressWarnings("unchecked")और @SuppressWarnings("null")उपरोक्त तरीकों का उपयोग करता हूं, लेकिन मुझे अपने संदेह हैं। यह Stackoverflow प्रश्न मिला । जॉन स्कीट ने इसका उत्तर लिखा, जो मुझे पेचीदा लगता है।

उसके अनुसार,

कभी-कभी जावा जेनेरिक बस आपको वह नहीं करने देता जो आप करना चाहते हैं, और आपको कंपाइलर को प्रभावी ढंग से यह बताने की जरूरत है कि आप जो कर रहे हैं वह वास्तव में निष्पादन के समय कानूनी होगा।

लेकिन क्या होगा अगर एक मौका है कि एक अपवाद फेंक दिया जाएगा? तब एक बुरा विचार चेतावनी को दबा नहीं रहा है? क्या मुझे उन जगहों के बारे में पता नहीं होना चाहिए जहाँ समस्याएं सतह पर हो सकती हैं?

इसके अलावा, क्या होगा अगर कोई और बाद में मेरे कोड को संशोधित करता है और सप्रेसवर्निंग को हटाए बिना कुछ संदिग्ध कार्यक्षमता जोड़ता है? इससे कैसे बचा जा सकता है और / या इसका कोई और विकल्प है?

क्या मुझे उपयोग करना चाहिए @SuppressWarnings("unchecked")और @SuppressWarnings("null")?

---

अपडेट # 1

जहाँ तक अनियंत्रित प्रकार की जातियाँ हैं, इस उत्तर के अनुसार (नीचे टिप्पणी में @gnat द्वारा इंगित), इन चेतावनियों को दबाना आवश्यक है।

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

अन्य चेतावनियों को दबाने के मामले में, अभी भी थोड़ा ग्रे क्षेत्र में।

---

अद्यतन # 2

ओरेकल डॉक्स के अनुसार (नीचे कुछ उत्तरों द्वारा भी उल्लेख किया गया है):

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

Comments

के संभावित डुप्लिकेट क्यों एक अक्षम संकलक चेतावनी करना चाहते हैं चाहिए?

— gnat

@gnat वे अनियंत्रित प्रकार के बारे में बात नहीं करते हैं

— बिलेश गांगुली

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

— gnat

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

Answer 1

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

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

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

संपादित करें

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

Comments

मैं आंशिक रूप से सहमत हूं कि "क्लीन" स्लेट से शुरू होने से आपको बाद में चेतावनी देने में मदद मिलती है, तथ्य यह है कि कोड जो सफाई से संकलित करता है, वह सफाई से नहीं चल सकता है।

— user949300

मेरे पास काम पर जो समस्या है, वह यह है कि मैं अक्सर उन चेतावनियों में भाग लेता हूं, जो किसी और ने दबा दी क्योंकि वे समझ नहीं पाए कि यह क्या कह रहा था। इसलिए मुझे लगता है कि चेतावनी में योग्यता है या नहीं यह एक व्यक्तिपरक मामला है। : /

— ट्रेकजाज़

Answer 2

दमन की चेतावनी एक ऐसी चीज है जिसे अत्यधिक सावधानी से करने की आवश्यकता है।

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

if (x = someFunction ()) { ... }

एक चेतावनी देता है लेकिन

if ((x = someFunction ())) { ... }

ऐसा नहीं करता। पहले मामले में एक चेतावनी है कि आप संभवतः == और नहीं = मतलब है। दूसरे मामले में कोई चेतावनी नहीं है क्योंकि अतिरिक्त कोष्ठक संकलक को "मैं जानता हूं कि मैं क्या कर रहा हूं" बताता हूं। बेशक बेहतर होगा

if ((x = someFunction ()) != 0) { ... }

या दो लाइनों का उपयोग कर।

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

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

Comments

मुझे लगता है कि आपको अपने दूसरे और तीसरे उदाहरण में कुछ बंद कोष्ठक याद आ रहे होंगे।

— 8bittree

अंतिम वाक्य से पूरी तरह सहमत

— usr-local-'Jan

Answer 3

संपूर्ण विधि के लिए चेतावनी को दबाना संदिग्ध है। टिप्पणी के साथ विशिष्ट लाइन के लिए चेतावनी को दबाने के लिए बेहतर है । जैसे

@SuppressWarnings("unchecked") Foo foo = (Foo)object; // Using old library requires this cast