Re: Closing decorated streams
Lew wrote:
One way is to chain the I/O classes in separate try-catch blocks, so
that a later nullity check is unnecessary; you can use 'assert'
statements instead. The result is verbose but precise control over
what happens and how it's logged, and the safety of assertably
initialized streams and readers.
public static void main( String [] args )
{
final InputStream is;
try
{
is = url.openStream();
}
catch ( IOException exc )
{
logger.error( "Cannot open URL stream. " + exc.getMessage() );
return;
}
assert is != null;
final BufferedReader br;
try
{
br = new BufferedReader( new InputStreamReader( is ));
}
catch ( IOException exc )
{
logger.error( "Cannot open URL stream reader. " + exc.getMessage
() );
try
{
is.close();
}
catch ( IOException closex )
{
logger.error( "Cannot close URL stream. " + closex.getMessage
() );
}
return;
}
assert br != null;
try
{
for ( String line; (line = br.readLine()) != null; )
{
System.out.println(line);
}
}
catch ( IOException exc )
{
logger.error( "Cannot read URL stream reader. " + exc.getMessage
() );
}
finally
{
try
{
br.close();
}
catch ( IOException closex )
{
logger.error( "Cannot close URL stream reader. " +
closex.getMessage() );
}
}
}
Knute Johnson wrote:
That's a pattern I've not seen before and I really like it, especially
the for loop for reading the lines. The return in the catch block is
pretty nifty too.
The return in the catch block is necessary to ensure the asserted invariant.
I am curious though if you really think that all those levels are really
necessary? The only place that can throw an I/O exception is the
URL.getInputStream() method and if it succeeds then the BufferedReader
constructor will succeed. So closing the BufferedReader will suffice.
I agree with you in this case. So the first try block would handle:
final BufferedReader br;
try
{
br = new BufferedReader( new InputStreamReader( url.openStream() ));
}
catch ( IOException exc )
{
logger.error( "Cannot open URL stream reader. " + exc.getMessage() );
return;
}
assert br != null;
The next try block would actually use 'br' and close it in its finally block.
The example I gave first was to address the OP's specific concern that the
reader assignments might fail separately from the stream retrieval, and to
illustrate the flexibility of the technique. Notice how easily the idiom
refactors to increase or decrease level of detail and granularity of control
by simply splitting out or merging try-catch blocks. The key to the idiom is
that one or more try-catch blocks establish an invariant of a valid resource
handle (the stream or reader instance), and a separate try-finally block (with
possible catch clauses) uses that guaranteed resource and disposes of it in
its finally section.
--
Lew