Is this code correct?

I was searching in whidbey documentation and I found this code there:

using System;
using System.IO;

class MyStream
{
   private const string FILE_NAME = "Test.data";
   public static void Main(String[] args) 
   {
      // Create the new, empty data file.
      if (File.Exists(FILE_NAME)) 
      {  
         Console.WriteLine("{0} already exists!", FILE_NAME);
         return;
      }

      FileStream fs = new FileStream(FILE_NAME, FileMode.CreateNew);
      // Create the writer for data.
      BinaryWriter w = new BinaryWriter(fs);
      // Write data to Test.data.
      for (int i = 0; i < 11; i++) 
      {
         w.Write( (int) i);
      }  
      w.Close();
      fs.Close();
      // Create the reader for data.
      fs = new FileStream(FILE_NAME, FileMode.Open, FileAccess.Read);
      BinaryReader r = new BinaryReader(fs);

      // Read data from Test.data.
      for (int i = 0; i < 11; i++) 
      {
         Console.WriteLine(r.ReadInt32());
      }
      w.Close();
   }
}

Look at last w.Close() command.  They close BinaryWriter which is already closed and they do not close BinaryReader r and FileStream fs.
I would close BinaryReader and then FileStream(as always).
So my question is: Is this mistake in documentation or am I barking up the wrong tree?

Actually, I think they should be using using.

Charles wrote:

Yeah, using is a pattern that works nicely, but technically there's nothing wrong with being explicit. The using pattern is useful and clean. I agree.

When not using using (which is possible of course), at least the above sample should be using try/finally blocks (something which using takes care of automatically).

Just out of curiosity (since I did actually see the question), what did you think it was?

Charles wrote:

I was looking at another code fragment in another window which used a catch-all exception pattern ( catch(Exception e) ),which is a terrible idea for most cases for a number of reasons...

God I hate this!! This is the second time in one week that Lijbrandt's authentication kicks in when I click post causing me to lose the post!

Anyway, for the second time:
There are still a few more general code quality comments I could make: using both string and String, using an args version of Main even though they're not using args, casting an int to an int, and using an all-caps constant.

And concerning catch-alls, sometimes it happens that I need to execute the same code for two or more different exceptions, who have no common base other than Exception or maybe SystemException, both of which are too general to use. This is an example where that might occur:
try
{
  // Some IO operation
}
catch( IOException ex )
{
  Throw new ExcellentException("Dude, it totally failed!", ex);
}
catch( UnauthorizedAccessException ex )
{
  Throw new ExcellentException("Dude, it totally failed!", ex);
}
(sorry, I've been watching Bill & Ted's Bogus Journey tonight)

In VB one might solve this using "Catch ex As Exception Where TypeOf ex Is IOException OrElse TypeOf ex Is UnauthorizedAccessException", but that's not possible in C#. Can this be solved elegantly in C#? Is there perhaps altogether a better way to go about this? Or is my code ill-designed for needing this in the first place?

Sven Groot wrote:

When not using using (which is possible of course), at least the above sample should be using try/finally blocks (something which using takes care of automatically).

The thing is that above sample is code fragment from documentation, therefore it's not necessary to have try/finally blocks there. If there were try/finally blocks in every sample in documentation it would be probably annoying. But things like close opened file (file.Close()) should be even in sample code!
But if we are talking about production code you are 100% RIGHT!!!

I don't agree. If sample code does not teach best practices, then how are you going to learn them?

Of course, that's just my opinion.

Maybe it's about time and resources that Microsoft is willing(can) to spend to create documentation. It's hard to find golden mean.
As here are guys from Microosft they could tell us something about how documentation is creating and what are priorities in creating documentation?

Sven Groot wrote:

I don't agree. If sample code does not teach best practices, then how are you going to learn them?

Of course, that's just my opinion.

It depends what the sample code is intended to demonstrate. Too much boilerplate error checking code can dilute the example you're trying to make.

Charles wrote:

(the docs are beta as well )

I was wondering, are they constantly revising these personally and they will fix themselves if users don't catch them or do they remain unchanged until they recieve input?