This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
No, the code in finally, behaves as any of the code in Java, so it must declare or handle the exception that is thrown by the called code. So You can surround stream.close() with try and catch, or throw the exception in the declaration of the method that is calling this code.
Welcome to the Ranch Paweł Michalak. You are correct about the Exception from the finally block.
What you want is this sort of thing:That ensures that if you can actually open your reader, it is closed, because the finally block is always executed whether or not the try suffers an Exception. Since the close() method declares a checked Exception, having it inside the outer try ensures that Exception is handled too.
I have added lots of comments to try and make the control flow easier to see. Probably more than you would want in real life. The format for file streams, data input streams, writers, etc, is very similar.
Ugh. That code looks horrible, because of the null checks and all. And you don't even need those:
I do this all the time - try+finally to make sure the resource is closed, wrapped inside a try+catch to catch any exceptions occurred inside the block.
There is one issue with this, both in your code and mine. If inRead.close() throws an IOException it will overwrite any IOException thrown by the remainder of the code.
Nothing, I was just kidding, and definitely not referring to your age (which I actually don't even know; all I know is you're older than me, but 35 is already older than me). Perhaps that statement would be better if I'd replace "old" with "experienced".