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.