Skip to main content

Timeline for Closing inputstreams in Java

Current License: CC BY-SA 3.0

25 events
when toggle format what by license comment
S Nov 29, 2016 at 10:25 history suggested Krishna Chaitanya CC BY-SA 3.0
Fixed broken link for Apache Commons IOUtils javadoc
Nov 29, 2016 at 9:37 review Suggested edits
S Nov 29, 2016 at 10:25
Jul 2, 2012 at 9:02 comment added Fabian Barney Well, I posted some code that clearly shows why this pattern is right and should be used. And it isn't my personal bullshit mind but a very common and accepted pattern. Headbanging isn't my profession but Albert Einstein comes into my mind: "Make things as simple as possible, but not simpler." Don't forget the last part ...
Jul 2, 2012 at 1:49 comment added Tom Hawtin - tackline bangs head against wall How can you release something that has not been acquired? Do not conflate try-finally and try-catch (like the Java language does). One (genuine) resource pre try-finally. Using nulls here not only complicates the code, but frequently introduces (sad case) bugs. Even when pointed out, it often gets incorrectly fixed. Keep it simple.
Jun 29, 2012 at 17:25 history edited Fabian Barney CC BY-SA 3.0
deleted 42 characters in body
Jun 29, 2012 at 17:20 history edited Fabian Barney CC BY-SA 3.0
added 481 characters in body; added 3 characters in body
Jun 29, 2012 at 17:11 history edited Fabian Barney CC BY-SA 3.0
added 243 characters in body
Jun 29, 2012 at 17:04 history edited Fabian Barney CC BY-SA 3.0
added 283 characters in body; added 1 characters in body
Jun 29, 2012 at 16:33 comment added Bruno The pattern you describe is indeed useful when you are using multiple streams.
Jun 29, 2012 at 16:23 history edited Fabian Barney CC BY-SA 3.0
deleted 151 characters in body
Jun 29, 2012 at 15:59 history edited Fabian Barney CC BY-SA 3.0
added 701 characters in body; added 210 characters in body
Jun 29, 2012 at 15:24 history edited Fabian Barney CC BY-SA 3.0
added 22 characters in body
Jun 29, 2012 at 15:18 history edited Fabian Barney CC BY-SA 3.0
added 13 characters in body
Jun 29, 2012 at 15:14 comment added Bruno Well, I think the acquire(); try { use(); } finally { release(); } block must be within a within a try/catch (IOException ...) block (or method with throws), not necessarily with a finally block or extra variables, simply because both close and the constructor can throw it. In this case, having the new BufferedReader statement in or outside your block doesn't change anything. It wouldn't reach the finally statement if an exception was thrown during the acquire() statement anyway.
Jun 29, 2012 at 15:11 comment added Fabian Barney Right, in that case you must declare a second variable outside the try-block and close it separatly in the finally block. But this is not possible with @TomHawtin-tackline advice, because with his advice it is generally impossible to release when error while acquire occurs.
Jun 29, 2012 at 15:09 comment added Bruno Just saying, here, in your example, if new BufferedReader(...) fails, an IOException will be thrown outside the scope of these lines (and in.close() will not be executed since in will be null). If you put the initialisation with the declaration BufferedReader in = new (...) above, the exact same thing will happen if an exception is thrown anyway.
Jun 29, 2012 at 15:08 history edited Fabian Barney CC BY-SA 3.0
added 65 characters in body
Jun 29, 2012 at 15:07 comment added Fabian Barney It is useful and totally standard pattern. It is so common that there exist Utility-Methods in Apache Commons IOUtils for it. Sorry, but he's simply wrong here.
Jun 29, 2012 at 15:06 comment added Bruno I think what Tom Hawtin is trying to say is that this null-testing pattern isn't useful in this case. If you don't get past the initialisation, it will throw an IOException. Since you're not catching it anyway, it's not going to change anything. In addition, you'd have to catch it in an outer try/catch for in.close() in the finally block anyway.
Jun 29, 2012 at 15:05 comment added Fabian Barney @TomHawtin-tackline So you do not realease when acquire raises an Exception? This is bad, especially when using special OutputStreams like TeeOutputStream where creation of one already proceeded and the other one fails.
Jun 29, 2012 at 15:00 comment added Fabian Barney @Bruno Right - that's what I meant in the last paragraph.
Jun 29, 2012 at 14:59 comment added Tom Hawtin - tackline acquire(); try { use(); } finally { release(); }
Jun 29, 2012 at 14:57 comment added Fabian Barney This is the normal pattern. What else you want to do?
Jun 29, 2012 at 14:56 comment added Tom Hawtin - tackline Please don't do that sort of null dance. It's a continual source of errors for obvious reasons. And what a mess.
Jun 29, 2012 at 14:55 history answered Fabian Barney CC BY-SA 3.0
toggle format