जब java.lang.Error को पकड़ने के लिए?

वोट
101

क्या स्थितियों में एक पकड़ने चाहिए java.lang.Errorएक आवेदन पर?

09/12/2008 को 14:56
का स्रोत उपयोगकर्ता
अन्य भाषाओं में...                            


16 जवाब

वोट
87

आम तौर पर, कभी नहीं। लेकिन, कभी कभी आप विशिष्ट त्रुटियाँ पकड़ने के लिए की जरूरत है।

आप ढांचे-ish कोड (3 पार्टी वर्गों लोड हो रहा है) लिख रहे हैं, यह LinkageErrors (कोई वर्ग डीईएफ़ पाया, असंतुष्ट लिंक, असंगत वर्ग परिवर्तन) को पकड़ने के लिए बुद्धिमान हो सकता है। मैं भी कुछ बेवकूफ 3 पार्टी ऑफ एरर्स sublcasses फेंकने कोड को देखा है, तो आप इन दोनों को संभालने के लिए होगा।

वैसे, मैं इसे OutOfMemory से उबरने के लिए संभव नहीं है यकीन नहीं है।

09/12/2008 को 15:12
का स्रोत उपयोगकर्ता

वोट
46

कभी नहीँ। आप यह सुनिश्चित करें कि आवेदन कोड की अगली पंक्ति पर अमल करने में सक्षम है कभी नहीं हो सकता है। आप एक मिलता है OutOfMemoryError, आपके पास कोई गारंटी नहीं है कि आप मज़बूती से कुछ भी करने को सक्षम हो जाएगा । RuntimeException पकड़ो और अपवाद की जाँच की, लेकिन कभी त्रुटियाँ।

http://pmd.sourceforge.net/rules/strictexception.html

09/12/2008 को 15:00
का स्रोत उपयोगकर्ता

वोट
16

आम तौर पर आप हमेशा पकड़ने चाहिए java.lang.Errorऔर यह एक लॉग में लिख सकते हैं या उपयोगकर्ता के लिए यह प्रदर्शित करते हैं। मैं समर्थन में काम करते हैं और दैनिक देख प्रोग्रामर नहीं बता सकता कि क्या एक कार्यक्रम में हुआ है।

यदि आप एक डेमॉन धागा है तो आप को रोकने चाहिए कि यह समाप्त किया जा रहा। अन्य मामलों में अपने आवेदन सही ढंग से काम करेंगे।

आप केवल पकड़ने चाहिए java.lang.Errorउच्चतम स्तर पर।

आप त्रुटियों की सूची को देखें, तो आपको लगता है कि सबसे संभाला जा सकता है देखेंगे। उदाहरण के लिए एक ZipErrorभ्रष्ट ज़िप फ़ाइलों को पढ़ने पर होता है।

सबसे आम त्रुटियाँ हैं OutOfMemoryErrorऔर NoClassDefFoundError, जो दोनों ज्यादातर मामलों क्रम समस्याओं में हैं।

उदाहरण के लिए:

int length = Integer.parseInt(xyz);
byte[] buffer = new byte[length];

एक उत्पादन कर सकते हैं OutOfMemoryErrorलेकिन यह एक क्रम समस्या नहीं है और अपने कार्यक्रम को समाप्त करने का कोई कारण नहीं है।

NoClassDefFoundErrorज्यादातर तब आते हैं, एक पुस्तकालय मौजूद नहीं है या आप एक और जावा संस्करण के साथ काम करता है, तो। यदि यह अपने कार्यक्रम के एक वैकल्पिक हिस्सा है तो आप अपने कार्यक्रम को समाप्त नहीं करना चाहिए।

मैं क्यों यह एक अच्छा विचार को पकड़ने के लिए है के कई और उदाहरण दे सकते हैं Throwableशीर्ष स्तर पर और एक सहायक त्रुटि संदेश का उत्पादन।

05/03/2009 को 13:29
का स्रोत उपयोगकर्ता

वोट
14

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

उदाहरण के लिए, आम तौर पर पाश होना चाहिए:

try {
   while (shouldRun()) {
       doSomething();
   }
}
catch (Throwable t) {
   log(t);
   stop();
   System.exit(1);
}

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

07/03/2009 को 17:39
का स्रोत उपयोगकर्ता

वोट
7

बहुत मुश्किल से।

मैं केवल आदेश एक धागा मरने के लिए कारण के साथ एक संदेश जारी करने के लिए प्रयास करने के लिए में एक धागा के शीर्ष स्तर पर कहना चाहते हैं।

आप एक रूपरेखा है कि आप के लिए बात की इस तरह करता है में हैं, तो यह ढांचे के लिए छोड़ दें।

09/12/2008 को 15:15
का स्रोत उपयोगकर्ता

वोट
6

यदि आपके पास पर्याप्त एक नया इकाई परीक्षण रूपरेखा बनाने जा करने के लिए पागल हैं, तो अपने परीक्षण धावक शायद java.lang.AssertionError किसी भी परीक्षा मामलों द्वारा फेंका पकड़ने के लिए की आवश्यकता होगी।

अन्यथा, अन्य उत्तर देखें।

10/12/2008 को 21:44
का स्रोत उपयोगकर्ता

वोट
6

एक Errorआम तौर पर पकड़ा नहीं किया जाना चाहिए , क्योंकि यह एक असामान्य स्थिति है कि हो कभी नहीं करना चाहिए इंगित करता है

के लिए जावा API विनिर्देश से Errorवर्ग:

एक Errorका एक उपवर्ग है Throwable कि गंभीर समस्याओं है कि एक उचित आवेदन को पकड़ने की कोशिश नहीं करनी चाहिए इंगित करता है। इस तरह के ज्यादातर त्रुटियों असामान्य स्थितियों रहे हैं। [...]

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

विनिर्देश उल्लेख के रूप में, एक Errorही परिस्थितियों है कि संभावना है कि, एक जब कर रहे हैं में फेंक दिया जाता है Error(जैसे होता है, वहाँ बहुत कम आवेदन कर सकते हैं, और कुछ परिस्थितियों में, जावा वर्चुअल मशीन अपने आप में एक अस्थिर अवस्था में हो सकता है VirtualMachineError)

हालांकि एक Errorएक उपवर्ग है की Throwableजिसका अर्थ है कि यह एक से पकड़ा जा सकता है try-catchखंड, लेकिन यह शायद वास्तव में जरूरत नहीं है, के रूप में आवेदन एक असामान्य स्थिति में होगा, जब एक ErrorJVM द्वारा फेंक दिया है।

वहाँ भी धारा में इस विषय पर एक छोटा भाग है 11.5 अपवाद पदानुक्रम के जावा भाषा विशिष्टता, 2 संस्करण

09/12/2008 को 15:18
का स्रोत उपयोगकर्ता

वोट
6

लगभग नहीं। त्रुटियाँ मुद्दों है कि आवेदन पत्र आम तौर पर के बारे में कुछ नहीं कर सकते करने के लिए डिज़ाइन कर रहे हैं। एकमात्र अपवाद त्रुटि की प्रस्तुति को संभालने के लिए हो सकता है लेकिन फिर भी यह है कि के रूप में त्रुटि के आधार पर योजना बनाई जाना नहीं हो सकता है।

09/12/2008 को 14:59
का स्रोत उपयोगकर्ता

वोट
5

और वहाँ अन्य मामलों अगर आप एक त्रुटि को पकड़ने, तुम कहाँ के एक जोड़े हैं यह rethrow करने के लिए है । उदाहरण के ThreadDeath पकड़ा जा कभी नहीं करना चाहिए, यह पैदा कर सकता है बड़ी समस्या है आप एक निहित वातावरण में इसे पकड़ (जैसे एक आवेदन सर्वर।):

एक आवेदन इस वर्ग के उदाहरणों को पकड़ने के केवल अगर यह अतुल्यकालिक रूप से समाप्त किया जा रहा करने के बाद साफ करना चाहिए करना चाहिए। ThreadDeath एक विधि द्वारा पकड़ा जाता है, तो यह महत्वपूर्ण है यह rethrown जा सकता है कि इतना है कि धागा वास्तव में मर जाता है।

09/12/2008 को 15:09
का स्रोत उपयोगकर्ता

वोट
4

में बहुत ही मुश्किल।

मैं यह केवल एक बहुत बहुत विशिष्ट ज्ञात मामलों के लिए किया था। उदाहरण के लिए, java.lang.UnsatisfiedLinkError अगर दो फेंक जा सकता है स्वतंत्रता classloader लोड एक ही DLL। (मैं मानता हूँ कि मैं एक साझा classloader को जार बढ़ना चाहिए)

लेकिन सबसे सामान्य रूप में आप को पता है जब उपयोगकर्ता शिकायत करने के लिए आते हैं कि क्या हुआ में लॉग इन करने की जरूरत है। आप एक संदेश या उपयोगकर्ता के लिए एक पॉपअप, बल्कि उसके बाद चुपचाप मृत चाहते हैं।

C / C ++ में भी प्रोग्रामर, वे एक त्रुटि पॉप और बताओ कुछ लोगों को यह बाहर निकलने के (जैसे स्मृति विफलता) से पहले समझ में नहीं आता।

09/12/2008 को 15:28
का स्रोत उपयोगकर्ता

वोट
3

यह एक परीक्षण वातावरण में java.lang.AssertionError को पकड़ने के लिए काफी आसान है ...

27/11/2013 को 02:53
का स्रोत उपयोगकर्ता

वोट
3

एक Android आवेदन में मैं एक पकड़ने हूँ java.lang.VerifyError । एक पुस्तकालय है कि मैं उपयोग कर रहा हूँ ओएस के एक पुराने संस्करण और पुस्तकालय कोड के साथ उपकरणों में काम नहीं करेगा इस तरह के एक त्रुटि फेंक देते हैं। मैं निश्चित रूप से रनटाइम पर OS का संस्करण की जाँच करके त्रुटि से बचने के सकता है, लेकिन:

  • सबसे पुराने समर्थित एसडीके विशिष्ट पुस्तकालय के लिए भविष्य में बदल सकता
  • कोशिश पकड़ त्रुटि ब्लॉक एक बड़ा वापस गिरने तंत्र का हिस्सा है। कुछ विशिष्ट उपकरणों, हालांकि वे पुस्तकालय का समर्थन करने वाले हैं, अपवाद फेंक देते हैं। मैं गिरावट वापस समाधान का उपयोग करने VerifyError और सभी अपवाद को पकड़ने के।
14/03/2013 को 07:17
का स्रोत उपयोगकर्ता

वोट
2

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

05/05/2014 को 19:22
का स्रोत उपयोगकर्ता

वोट
1

वहाँ जब JVM कोई और अधिक काम कर रहा है के रूप में उम्मीद, या करने के लिए कगार पर है एक त्रुटि है। यदि आपको कोई त्रुटि पकड़ है, वहाँ कोई गारंटी नहीं है कि कैच ब्लॉक चलेंगे, और भी कम है कि यह अंत तक चलेंगे है।

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

आप भी अपने कोड की पठनीयता डाउनग्रेड हो जाएगी।

23/04/2013 को 17:50
का स्रोत उपयोगकर्ता

वोट
1

यह इकाई परीक्षण है कि जाँच एक अभिकथन किया जाता है के भीतर त्रुटि को पकड़ने के लिए उपयुक्त हो सकता है। किसी दावे को निष्क्रिय या अन्यथा तो अभिकथन आप जानना चाहते हैं हटाता

19/08/2012 को 21:35
का स्रोत उपयोगकर्ता

वोट
1

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

26/01/2011 को 07:23
का स्रोत उपयोगकर्ता

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more