जावा में "अप्राप्य कथन" संकलक त्रुटि क्यों है?

Question

मुझे अक्सर लगता है कि जब किसी प्रोग्राम को डिबग करना सुविधाजनक होता है, (हालांकि यकीनन बुरा अभ्यास) कोड के ब्लॉक के अंदर रिटर्न स्टेटमेंट डालने के लिए। मैं जावा में कुछ इस तरह की कोशिश कर सकते हैं ....

class Test {
        public static void main(String args[]) {
                System.out.println("hello world");
                return;
                System.out.println("i think this line might cause a problem");
        }
}

बेशक, यह संकलक त्रुटि उत्पन्न करेगा।

Test.java:7: अगम्य कथन

मैं समझ सकता हूं कि अनुपयोगी कोड को क्यों गलत ठहराया जा सकता है क्योंकि अनुपयोगी कोड खराब प्रथा है। लेकिन मुझे समझ में नहीं आता है कि यह एक त्रुटि उत्पन्न करने की आवश्यकता क्यों है।

क्या यह सिर्फ जावा एक नानी बनने की कोशिश कर रहा है, या क्या यह एक संकलक त्रुटि बनाने का एक अच्छा कारण है?

Comments

जावा इस बारे में पूरी तरह से सुसंगत नहीं है। कुछ नियंत्रण प्रवाह के लिए जो मृत कोड का कारण बनता है, लेकिन जावा शिकायत नहीं करता है। दूसरों के लिए यह करता है। यह निर्धारित करना कि कौन सा कोड मृत है, एक समस्या है। मुझे नहीं पता कि जावा ने कुछ ऐसा क्यों शुरू करने का फैसला किया जो खत्म नहीं हो सकता।

— पॉल ड्रेपर

Answer 1

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

यहाँ एक समान प्रश्न है: अप्राप्य कोड: त्रुटि या चेतावनी? , जिसमें लेखक कहता है "व्यक्तिगत रूप से मुझे दृढ़ता से लगता है कि यह एक त्रुटि होनी चाहिए: यदि प्रोग्रामर कोड का एक टुकड़ा लिखता है, तो यह हमेशा वास्तव में इसे कुछ परिदृश्य में चलाने के इरादे से होना चाहिए।" जाहिर है जावा के भाषा डिजाइनर सहमत हैं।

क्या अनुपलब्ध कोड को संकलन को रोकना चाहिए, एक ऐसा सवाल है जिस पर आम सहमति कभी नहीं होगी। लेकिन यह जावा डिजाइनरों ने ऐसा क्यों किया।

---

टिप्पणियों में कई लोग इंगित करते हैं कि अनुपलब्ध कोड जावा के कई वर्ग हैं जो संकलन को नहीं रोकता है। यदि मैं गोडेल के परिणामों को सही ढंग से समझता हूं, तो कोई संकलक संभवतः अगम्य कोड के सभी वर्गों को पकड़ नहीं सकता है।

यूनिट परीक्षण हर एक बग को पकड़ नहीं सकते हैं। हम उनके मूल्य के खिलाफ एक तर्क के रूप में इसका उपयोग नहीं करते हैं। इसी तरह एक कंपाइलर सभी समस्याग्रस्त कोड को नहीं पकड़ सकता है, लेकिन जब यह खराब कोड का संकलन कर सकता है तो इसे रोकना अभी भी मूल्यवान है।

जावा भाषा के डिजाइनर अप्राप्य कोड को एक त्रुटि मानते हैं। इसलिए जब संभव हो इसे संकलित करना रोकना उचित है।

---

(इससे पहले कि आप डाउनवोट करें: सवाल यह नहीं है कि जावा में एक अप्राप्य स्टेटमेंट कंपाइलर एरर होना चाहिए या नहीं। सवाल यह है कि जावा में अप्राप्य स्टेटमेंट कंपाइलर एरर है। मुझे सिर्फ इसलिए डाउनवोट न करें क्योंकि आपको लगता है कि जावा ने गलत डिजाइन निर्णय लिया है।)

Comments

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

— निकिता रायबाक

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

— सैमस्टीफेन्स

SamStephens: यह देखने के लिए कि बिना पढ़े हुए तरीके और अप्रयुक्त चर अनिवार्य रूप से अनुपलब्ध कोड के सभी रूप हैं। क्यों कुछ रूपों की अनुमति दें और दूसरों की नहीं? विशेष रूप से, इस तरह के एक उपयोगी डिबगिंग तंत्र को क्यों अस्वीकार करें?

— गाबे

टिप्पणियाँ भी अप्राप्य नहीं हैं? मेरे दिमाग में, अगम्य कोड वास्तव में टिप्पणियों का एक रूप है (यह वही है जो मैं पहले करने की कोशिश कर रहा था, आदि)। लेकिन "वास्तविक" टिप्पणियों को देखते हुए "पुनःप्राप्ति योग्य" भी नहीं हैं ... शायद उन्हें भी यह त्रुटि उठानी चाहिए;)

— ब्रैडी मोरिट्ज़

समस्या यह है कि वे (जावा भाषा डिजाइनर) इसके साथ असंगत हैं। यदि वहाँ वास्तविक प्रवाह विश्लेषण, यह एहसास है कि दोनों तुच्छ है return; System.out.println();और if(true){ return; } System.out.println();समान व्यवहार करने की गारंटी दी जाती है, लेकिन एक एक संकलन त्रुटि है, और अन्य नहीं है। इसलिए, जब मैं डिबगिंग कर रहा हूं, और मैं इस पद्धति का उपयोग अस्थायी रूप से "टिप्पणी" करने के लिए करता हूं, तो मैं इसे कैसे करता हूं। कोड को कमेंट करने में समस्या यह है कि आपको अपनी टिप्पणी को रोकने के लिए उपयुक्त स्थान ढूंढना होगा, जो return;वास्तविक त्वरित में फेंकने से अधिक समय ले सकता है ।

— लेडीकैलेन

Answer 2

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

if (true) return;

यह निरर्थक लगता है, जो कोई भी कोड पढ़ता है, वह अनुमान लगाएगा कि यह जानबूझकर किया गया होगा, बाकी बयानों को छोड़ देने में लापरवाही नहीं।

जावा में "सशर्त संकलन" के लिए थोड़ा सा समर्थन है

http://java.sun.com/docs/books/jls/third_edition/html/statements.html#14.21

if (false) { x=3; }

एक संकलन-समय त्रुटि में परिणाम नहीं करता है। एक अनुकूलन कंपाइलर को एहसास हो सकता है कि कथन x = 3; कभी भी निष्पादित नहीं किया जाएगा और उत्पन्न श्रेणी फ़ाइल से उस कथन के लिए कोड को छोड़ना चुन सकता है, लेकिन कथन x = 3; यहाँ निर्दिष्ट तकनीकी अर्थ में "अगम्य" नहीं माना जाता है।

इस भिन्न उपचार का औचित्य प्रोग्रामर्स को "ध्वज चर" को परिभाषित करने की अनुमति देना है:

static final boolean DEBUG = false;

और फिर कोड लिखें जैसे:

if (DEBUG) { x=3; }

यह विचार यह है कि DEBUG के मूल्य को असत्य से सत्य में या असत्य से असत्य में बदलना संभव है और फिर कोड को प्रोग्राम पाठ में कोई अन्य परिवर्तन न करके सही ढंग से संकलित करना चाहिए।

Comments

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

— समस्टीफेन्स

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

— रॉबर्ट

"जो कोई भी कोड पढ़ता है, वह अनुमान लगाएगा कि यह जानबूझकर किया गया होगा"। मेरी राय में यह बिल्कुल समस्या है, लोगों को अनुमान नहीं लगाना चाहिए, उन्हें समझना चाहिए। याद रखने वाला कोड लोगों के साथ संचार है, न कि केवल कंप्यूटर के लिए निर्देश। यदि यह बेहद अस्थायी के अलावा कुछ भी है, तो आपको मेरी राय में कॉन्फ़िगरेशन का उपयोग करना चाहिए। जो आप ऊपर दिखा रहे हैं उसे देखते हुए, if (true) return;यह इंगित नहीं करता कि आप तर्क को क्यों छोड़ रहे हैं, जबकि if (BEHAVIOURDISABLED) return;इरादा संचार करता है।

— सैमस्टीफेंस

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

— बिल के

Answer 3

यह नानी है। मुझे लगता है कि .Net को यह एक अधिकार मिल गया है - यह अगम्य कोड के लिए चेतावनी देता है, लेकिन त्रुटि नहीं। इसके बारे में चेतावनी देना अच्छा है, लेकिन मुझे संकलन को रोकने का कोई कारण नहीं दिखता है (विशेषकर डिबगिंग सत्र के दौरान जहां कुछ कोड को बायपास करने के लिए रिटर्न फेंकना अच्छा है)।

Comments

जावा को पहले से डिज़ाइन किया गया था, उस समय प्रत्येक बाइट मायने रखती थी, फ्लॉपी डिस्क अभी भी उच्च तकनीक थी।

— 22

डीबग आरंभिक वापसी के लिए, आपकी आरंभिक वापसी के बाद की पंक्तियों पर टिप्पणी करने में पाँच सेकंड लगते हैं। अगम्य कोड को एक त्रुटि बनाकर रोके गए बग के लिए खेलने के लिए एक छोटी सी कीमत।

— समस्टीफेन्स

कंपाइलर के लिए अगम्य कोड को बाहर करना भी आसान है। डेवलपर को ऐसा करने के लिए मजबूर करने का कोई कारण नहीं।

— ब्रैडी मोरित्ज़

@SamStephens यदि आपके पास पहले से ही कोई टिप्पणी नहीं है, क्योंकि टिप्पणियां स्टैक नहीं करती हैं, तो टिप्पणियों के साथ इसके चारों ओर काम करने के लिए अनावश्यक दर्द है।

— 0

@SamStephens ने टिप्पणी की कि कोड अच्छी तरह से रिफैक्टर नहीं करता है।

— 23-28 को काउलिन्टर

Answer 4

मैंने केवल इस प्रश्न पर ध्यान दिया है, और मैं अपना $ .02 इसमें जोड़ना चाहता हूं।

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

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

स्टैक मैप्स को सत्यापित करने के लिए, VM को उन सभी कोड रास्तों से गुजरना पड़ता है जो एक विधि में मौजूद होते हैं, और यह सुनिश्चित करते हैं कि कोई भी कोड पथ कभी भी निष्पादित नहीं होगा, हर निर्देश के लिए स्टैक डेटा किसी भी पिछले कोड को धक्का देने से सहमत है। / स्टैक में संग्रहीत। तो, के सरल मामले में:

Object a;
if (something) { a = new Object(); } else { a = new String(); }
System.out.println(a);

पंक्ति 3 पर, JVM यह जाँच करेगा कि 'अगर' की दोनों शाखाएँ केवल एक में संग्रहीत की गई हैं (जो कि सिर्फ स्थानीय संस्करण # 0 है) कुछ ऐसा है जो ऑब्जेक्ट के साथ संगत है (क्योंकि यह पंक्ति 3 से कोड है और स्थानीय संस्करण # 0 का इलाज करेगा। )।

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

बेशक एक साधारण स्थिति if (1<2)इसे बेवकूफ बना देगी, लेकिन यह वास्तव में मूर्खतापूर्ण नहीं है - यह इसे एक संभावित शाखा दे रहा है जिससे कोड हो सकता है, और कम से कम कंपाइलर और वीएम दोनों निर्धारित कर सकते हैं कि स्टैक आइटम का उपयोग कैसे किया जा सकता है। पर।

PS मुझे नहीं पता कि .NET इस मामले में क्या करता है, लेकिन मेरा मानना ​​है कि यह संकलन को भी विफल कर देगा। यह आमतौर पर किसी भी मशीन कोड कंपाइलर (C, C ++, Obj-C, आदि) के लिए कोई समस्या नहीं होगी।

Comments

जावा की डेड कोड चेतावनी प्रणाली कितनी आक्रामक है? क्या इसे व्याकरण के भाग के रूप में व्यक्त किया जा सकता है (जैसे { [flowingstatement;]* }=> flowingstatement, { [flowingstatement;]* stoppingstatement; }=> stoppingstatement, return=> stoppingstatement, if (condition) stoppingstatement; else stoppingstatement=> stoppingstatement;इत्यादि?

— सुपरकैट

मैं व्याकरण से अच्छा नहीं हूं, लेकिन मेरा मानना ​​है कि हां। हालांकि, "रोकना" स्थानीय हो सकता है, उदाहरण के लिए एक लूप के अंदर "ब्रेक" स्टेटमेंट। साथ ही, विधि का अंत विधि स्तर के लिए एक अंतर्निहित रोक कथन है, यदि विधि शून्य है। 'थ्रो' भी एक स्पष्ट रोक कथन होगा।

— पावेल वेसेलोव 22

जावा मानक void blah() { try {return;} catch (RuntimeError ex) { } DoSomethingElse(); } क्या कुछ के बारे में कहेगा जैसे जावा स्क्वाक होगा कि tryब्लॉक वास्तव में एक अपवाद के माध्यम से बाहर नहीं निकल सकता था, या क्या यह पता लगाएगा कि किसी भी tryब्लॉक में किसी भी प्रकार का अनियंत्रित अपवाद हो सकता है ?

— सुपरकैट

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

— पावेल वेसेलोव

असल में, सवाल यह है कि क्या केवल निषिद्ध "अगम्य" कथन वे हैं जिन्हें पार्सिंग के आधार पर अप्राप्य के रूप में पहचाना जा सकता है, वास्तव में किसी भी अभिव्यक्तियों का मूल्यांकन किए बिना, या क्या मानक जैसे अगम्य बयानों को मना कर सकता है if (constantThatEqualsFive < 3) {doSomething;};।

— 23 अक्टूबर को सुपरकैट

Answer 5

संकलक के लक्ष्यों में से एक त्रुटियों के वर्गों को बाहर करना है। कुछ पहुंच से बाहर कोड है दुर्घटना से, यह अच्छा है कि javac संकलन समय पर त्रुटि के उस वर्ग को बाहर निकालता है।

गलत कोड को पकड़ने वाले हर नियम के लिए, कोई व्यक्ति संकलक को यह स्वीकार करना चाहेगा क्योंकि वे जानते हैं कि वे क्या कर रहे हैं। यह संकलक जाँच का दंड है, और संतुलन सही होना भाषा डिजाइन के चालबाज बिंदुओं में से एक है। यहां तक ​​कि सख्त जाँच के साथ अभी भी कई अनंत कार्यक्रम हैं जिन्हें लिखा जा सकता है, इसलिए चीजें इतनी बुरी नहीं हो सकती हैं।

Answer 6

जबकि मुझे लगता है कि यह संकलक त्रुटि एक अच्छी बात है, एक तरीका है जिससे आप इसके आसपास काम कर सकते हैं। एक शर्त का उपयोग करें जिसे आप जानते हैं कि यह सच होगा:

public void myMethod(){

    someCodeHere();

    if(1 < 2) return; // compiler isn't smart enough to complain about this

    moreCodeHere();

}

कंपाइलर इतना स्मार्ट नहीं है कि उसकी शिकायत करे।

Comments

यहाँ सवाल यह है कि क्यों? अप्राप्य कोड संकलक के लिए अर्थहीन है। तो इसके लिए एकमात्र दर्शक डेवलपर्स है। एक टिप्पणी का उपयोग करें।

— समस्टीफेन्स

इसलिए मैं नीचे उतर जाता हूं क्योंकि मैं उस तरह से सहमत हूं जिस तरह से जावा लोगों ने अपने संकलन को त्याग दिया था? जीज ...

— शॉन पैट्रिक फ्लोयड

आप वास्तविक प्रश्न का उत्तर नहीं देने के लिए उतर जाते हैं। SamStephens की टिप्पणी देखें।

— BoltClock

javac निश्चित रूप से अनुमान लगा सकता है कि 1<2यह सच है, और बाकी विधि को बाइट कोड में शामिल नहीं करना है। "अप्राप्य कथनों" के नियम स्पष्ट, निर्धारित, और संकलक की स्मार्टनेस से स्वतंत्र होने चाहिए।

— अप्रचलित

@ उस रवैये के साथ, आप इस साइट के सबसे अच्छे उत्तर के 50% को कम करने जा रहे हैं (और मैं यह नहीं कह रहा हूँ कि मेरा उत्तर उन में से है)। एसओ पर प्रश्नों के उत्तर देने का एक बड़ा हिस्सा, जैसा कि किसी भी आईटी परामर्श स्थिति में है, किसी दिए गए प्रश्न से वास्तविक प्रश्न (या प्रासंगिक पक्ष प्रश्न) की पहचान करना है।

— सीन पैट्रिक फ्लोयड

Answer 7

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

Answer 8

यदि अनुमति देने if (aBooleanVariable) return; someMoreCode;का कारण झंडे की अनुमति देना है, तो यह तथ्य कि if (true) return; someMoreCode;संकलन समय त्रुटि उत्पन्न नहीं करता है, कोडनोट्रेचेबल अपवाद को उत्पन्न करने की नीति में असंगति की तरह लगता है, क्योंकि संकलक 'जानता है' कि trueएक झंडा नहीं है (एक चर नहीं है)।

दो अन्य तरीके जो दिलचस्प हो सकते हैं, लेकिन एक विधि के कोड के भाग को स्विच करने के लिए भी लागू नहीं होते हैं if (true) return:

अब, कहने के बजाय if (true) return;आप कह सकते हैं assert falseऔर -ea OR -ea package OR -ea classNamejvm तर्कों को जोड़ना चाहते हैं । अच्छी बात यह है कि यह कुछ ग्रैन्युलैरिटी के लिए अनुमति देता है और jvm इनवोकेशन में एक अतिरिक्त पैरामीटर जोड़ने की आवश्यकता होती है, ताकि कोड में DEBUG फ्लैग सेट करने की कोई आवश्यकता न हो, लेकिन रनटाइम पर जोड़े गए तर्क द्वारा, जो तब उपयोगी नहीं होता है जब लक्ष्य नहीं होता है डेवलपर मशीन और फिर से लोडिंग और ट्रांसफ़ॉर्मिंग बायटेकोड में समय लगता है।

वहाँ भी System.exit(0)रास्ता है, लेकिन यह एक ओवरकिल हो सकता है, यदि आप इसे जावा में एक जेएसपी में डालते हैं तो यह सर्वर को समाप्त कर देगा।

इसके अलावा जावा एक 'नानी' भाषा है, मैं इसे अधिक नियंत्रण के लिए C / C ++ की तरह कुछ देशी उपयोग करूंगा।

Comments

एक static finalवैरिएबल से कुछ बदलना जो एक स्टैटिक इनिशियलाइज़ेशन ब्लॉक में एक static finalवैरिएबल में सेट किया गया है जो इसके डिक्लेरेशन में सेट है, एक ब्रेकिंग चेंज नहीं होना चाहिए। यह पूरी तरह से प्रशंसनीय है कि जब एक कक्षा पहली बार लिखी जाती है तो वह कभी-कभी कुछ करने में असमर्थ हो सकती है (और रन-टाइम तक ज्ञात नहीं है कि वह ऐसा कर पाएगी या नहीं), लेकिन कक्षा के बाद के संस्करण संभवत: सक्षम होंगे वह क्रिया हमेशा करें। myClass.canFooएक स्थिरांक में परिवर्तन को if (myClass.canFoo) myClass.Foo(); else doSomethingElse();अधिक कुशल बनाना चाहिए - इसे तोड़ना नहीं चाहिए ।

— सुपरकैट