2013-01-23 11 views
20

पहली नज़र में इस कोड को पूरी तरह से ठीकक्या java.io.BufferedOutputStream उपयोग करने के लिए सुरक्षित है?

BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream("1.txt")); 
byte[] bytes = new byte[4096]; 
bout.write(bytes); 
bout.close(); 

लगता है, लेकिन अगर हम गौर हम इस प्रकार

public void close() throws IOException { 
    try { 
     flush(); 
    } catch (IOException ignored) { 
    } 
    out.close(); 
} 

क्या यह संभव है कि कारण flush() त्रुटियों अनदेखी कर रहे हैं कि close() कार्यान्वित किया जाता है देखेंगे डेटा खो जा सकता है और कार्यक्रम इसे नोटिस नहीं करेगा? FilterOutputStream.close में किसी भी खतरे का कोई उल्लेख नहीं है (जहां BufferedOutputStream एआईपीआई से close() विरासत)।

अद्यतन: पास दौरान आईओ त्रुटि अनुकरण करने के लिए() मैं परीक्षण एक फ्लैश मेमोरी में लिखने के लिए बदल गया है, bout.close से पहले एक 5 सेकंड नींद जोड़ा() और जब तक परीक्षण सो रहा था मैं USB से फ्लैश हटाया । परीक्षण अपवादों के बिना समाप्त हुआ, लेकिन जब मैंने फ्लैश डाला और इसे चेक किया - 1.txt वहां नहीं था।

तब मैं overrode पास()

BufferedOutputStream bout = new BufferedOutputStream(new FileOutputStream("g:/1.txt")) { 
     @Override 
     public void close() throws IOException { 
      flush(); 
      super.close(); 
     } 
    }; 

और फिर से परीक्षण भाग गया और

Exception in thread "main" java.io.FileNotFoundException: g:\1.txt (The system cannot the specified path) 
    at java.io.FileOutputStream.open(Native Method) 
    at java.io.FileOutputStream.<init>(FileOutputStream.java:212) 
    at java.io.FileOutputStream.<init>(FileOutputStream.java:104) 
    at test.Test1.main(Test1.java:10) 
+0

'फ़िल्टरऑटपुटस्ट्रीम' टाइपो? –

+3

यह openjdk 'close()' विधि में एक बग के रूप में दिखाता है। - मृत स्टोर को अनदेखा करने के लिए ... –

+0

@ निकोलय नहीं। BufferedOuptutStream वहां से करीब विरासत में आता है, –

उत्तर

5

मिला यह है के रूप में, मैं कारण है कि फोन करने close वास्तव में आपको लगता है कि के बाद से डेटा खो देते हैं, कर सकते हैं संभावित IOException को चुपचाप अनदेखा किया जा रहा है (पृथ्वी पर कौन जानता है कि डेवलपर दिमाग के माध्यम से क्या किया गया ...)।

एक सभ्य विकल्प है, हालांकि यह प्रोग्रामर के पक्ष में मेहनत करता है, close से पहले स्पष्ट रूप से flush कॉल करने के लिए (संभावित IOException सही ढंग से निपटने), @Tom द्वारा एक टिप्पणी में उल्लेख किया है की तरह, विशेष रूप से एक try/finally ब्लॉक में है ।

AutoCloseable ऑब्जेक्ट्स के कारण, इस समस्या को जावा 7 में और बढ़ाया जा सकता है, क्योंकि आप स्पष्ट रूप से close() विधि को कॉल नहीं करेंगे और इस तरह के काम-आसपास से पर्ची करना आसान है।

+0

जैसे अधिक विवरण शामिल हैं क्योंकि संभवतया उन्हें दबाने वाले अपवाद नहीं थे, इसलिए उन्हें फ्लश() से अपवाद से निपटने का तरीका नहीं पता था। – irreputable

+1

मुझे लगता है कि अपवाद को फेंकना अभी भी सुरक्षित होगा और उपयोगकर्ता को स्पष्ट रूप से पता चलेगा कि कुछ गलत हो गया है। – pcalcao

संबंधित मुद्दे

 संबंधित मुद्दे