क्या आपने कभी जावा फ़ाइल बंद() अपवाद फेंक दिया है?

Question

क्या किसी ने कभी भी किसी भी बंद करने योग्य वस्तु पर बंद विधि को कॉल करते समय एक अपवाद फेंक दिया है?

Answer 1

IOExceptionclose पर फेंक दिया जाएगा यदि अंतिम flush विफल रहता है। संभावित कारणों में शामिल:

• फाइल सिस्टम भरा हुआ है, या उपयोगकर्ता कोटा खत्म हो गया है,
• हार्ड डिस्क त्रुटियों,
• एक फाइल सिस्टम जबरन अनमाउंट किए,
• एक दूरस्थ फाइल सिस्टम की वजह से अनुपलब्ध है नेटवर्किंग या अन्य समस्याओं,
• (संभवतः) एक वर्ण एन्कोडिंग त्रुटि है, तो एक OutputStreamWriter या इसी तरह के माध्यम से फाइल करने के लिए लेखन,
• एक डिवाइस त्रुटि है, तो "फाइल" एक उपकरण फ़ाइल है, करने के लिए
+०१२३५१६४१०
• एक खो कनेक्शन यदि closeable एक नेटवर्क धारा है,
• एक टूटी हुई पाइप अगर closeable बाहरी प्रक्रिया के लिए एक पाइप है,
• और इतने पर।

मैंने निश्चित रूप से इनमें से कुछ को देखा है। दूसरों की संभावना नहीं है।

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

Answer 2

मुझे लगता है कि आप डिस्क को अनप्लग करके अपनी फ़ाइल चालू कर सकते हैं। लेकिन किसी भी Closable पर? मुझे लगता है कि बंद करने पर अपवाद फेंकने के लिए सॉकेट का उपयोग करने वाला कुछ ऐसा आसान होगा।

Answer 3

मेरे पास नहीं है, लेकिन यह संभव है। कल्पना करें कि OutputStream है कि किसी कारण से अभी तक फ़ाइल में नहीं लिखा है। खैर, close() को कॉल करना डेटा को फ्लश करेगा, लेकिन अगर फ़ाइल लॉक है - तो IOException उठाया जाएगा।

Answer 4

हां, यह दुर्लभ नहीं है, IMHO यदि आप गैर-स्थानीय डिस्क फ़ाइलों के अलावा किसी अन्य चीज़ के साथ काम कर रहे हैं।

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

इसके अलावा, मैंने कोड देखा है जो खुले और लिखने पर त्रुटियों को अनदेखा करता है और अभी भी बंद करने की कोशिश करता है (उदाहरण के लिए, अंततः ब्लॉक में)।

Answer 5

फ़ाइल-आईओ के मामले में नहीं, लेकिन सॉकेट के मामले में करीब IOException उठाएगा जब दूसरी तरफ कनेक्शन को निरस्त कर दिया जाएगा। उदाहरण के लिए, जब आप एक (बड़े) वेबपृष्ठ पर HTTP अनुरोध को आग लगाते हैं और फिर वेबपृष्ठ पर एक और लिंक पर क्लिक करके तुरंत नेविगेट करते हैं (जब यह लोडिंग समाप्त नहीं होता है), तो सर्वर पक्ष को IOException (या उप-वर्ग ClientAbortException टॉमकैट सर्वर और क्लोन में) जब HTTP प्रतिक्रिया के आउटपुटस्ट्रीम को फ्लश/बंद किया जाना है।

Answer 6

मेरे पास है - mocks के खिलाफ मेरी इकाई परीक्षण में;)

Answer 7

उस पर एक खुली फ़ाइल के साथ एक यूएसबी ड्राइव yanking कोशिश करो। अगर यह अपवाद नहीं देता है तो मैं बहुत आश्चर्यचकित हूं।

Answer 8

पुरानी पोस्ट और लंबे समय के बाद से उत्तर दिया, लेकिन यहाँ एक वास्तविक उदाहरण है:

निम्नलिखित कोड बाहर सिवाय होगा जब bufferedWriter.close() कहा जाता है। ऐसा इसलिए होता है क्योंकि BufferedWriter के अंतर्निहित राइटर (फ़ाइलवाइटर) को पहले ही बंद कर दिया गया है और जब BufferedWriter बंद हो जाता है, तो यह पहले अपने बफर में किसी भी डेटा को इसके अंतर्निहित राइटर में फ्लश करने का प्रयास करता है।

File newFile = new File("newFile.txt"); 

FileWriter fileWriter = new FileWriter(newFile); 
BufferedWriter bufferedWriter = new BufferedWriter(fileWriter); 

bufferedWriter.write("Hello World"); 

fileWriter.close(); 
bufferedWriter.close(); 

नोट: वहाँ बफर में कोई डेटा उपलब्ध न तो [लिखने() लाइन बाहर टिप्पणी करते हैं या फ्लश() कॉल जोड़ने] तो कोई अपवाद नहीं