Thanks Peter!

BTW, I really enjoy your blog.

Sorry, I must have been out to lunch when I wrote. Initialize oProcessFileReader
to null when you declare it.

Best Regards,
Dustin Campbell
Developer Express Inc

...

   Do you mean that |reader| in your example is null? I am not sure
if memory for local variable declarations is primed with zeros. Is it
somewhere in the language specifications?

The compiler does notice that he's checking for null.  The problem is that
he's not allowed to check for null until he's set the variable to null.  He
really does have an uninitialized variable bug in his code.

In this particular case, there *is* a code path that can result in the local
variable being accessed before being initialized, without initialization in
the declaration.  Initializing the local variable is indeed the correct
solution to the error, and is also correct relative to the rest of the code
that was posted.

However, unfortunately the compiler sometimes also incorrectly complains
that the variable is uninitialized, even when all code paths *do* initialize
the variable before it's accessed.

IMHO, this is a serious compiler bug, because the only way to get rid of the
error is to put in a "dummy" initialization (such as setting the variable to
null), which consequentially will hide any true "uninitialized variable"
errors in the code.

In other words, with the compiler in the state in which it is now, there are
actually situations in which the compiler forces the programmer to write
code that is *more* likely to contain the bug that the error is trying to
help avoid.  I'd find the irony very entertaining, if it weren't for the
fact that there's a serious code quality issue related to it.  :)

Pete

Unfortunately, a using statement doesn't actually protect the code that was
protected before. It will compile to this:

StreamReader oProcessFileReader = File.OpenText(sFileName);
try
{
 // use the oProcessFileReader
}
finally
{
 if (oProcessFileReader != null)
   ((IDisposable)oProcessFileReader).Dispose();
}

So, if an exception is raised by File.OpenText(), the call stack will immediately
unwind and the try/finally code doesn't ever execute. IOW, the code that
you presented doesn't actually do the same thing. I suppose that you *could*
do this:

private void Test(string sFileName)
{
 try
 {
   using (StreamReader oProcessFileReader = File.OpenText(sFileName))
   {                        
     //use the oProcessFileReader
   }

   //here the stream has been disposed.
 }
 catch (Exception e)
 {
   MessageBox.Show("Error: " + e.Message);
 }
}

But, now the scope for try/catch is pretty different--it will also be catching
any exceptions thrown by code other than File.OpenText.

I don't think there's anyway to precisely re-write the original code with
a using statement.

Best Regards,
Dustin Campbell
Developer Express Inc.