don't have to close filestream?

  • Thread starter Thread starter mp
  • Start date Start date
M

mp

this example comes from msdn
http://msdn.microsoft.com/en-us/library/dsh84875.aspx
i notice they don't close filestream
is that ok?

private void DeserializeObject(string filename)
{
Console.WriteLine("Reading with Stream");
// Create an instance of the XmlSerializer.
XmlSerializer serializer =
new XmlSerializer(typeof(OrderedItem));
// Reading the XML document requires a FileStream.
Stream reader= new FileStream(filename,FileMode.Open);

// Declare an object variable of the type to be deserialized.
OrderedItem i;

// Call the Deserialize method to restore the object's state.
i = (OrderedItem) serializer.Deserialize(reader);

// Write out the properties of the object.
Console.Write(
i.ItemName + "\t" +
i.Description + "\t" +
i.UnitPrice + "\t" +
i.Quantity + "\t" +
i.LineTotal);
}

i also notice most samples don't null objects after use
is it ok to just let scope take care of destroying reference?

thanks
mark
 
this example comes from msdnhttp://msdn.microsoft.com/en-us/library/dsh84875.aspx
i notice they don't close filestream
is that ok?

 private void DeserializeObject(string filename)
   {
      Console.WriteLine("Reading with Stream");
      // Create an instance of the XmlSerializer.
      XmlSerializer serializer =
      new XmlSerializer(typeof(OrderedItem));
      // Reading the XML document requires a FileStream.
      Stream reader= new FileStream(filename,FileMode.Open);

      // Declare an object variable of the type to be deserialized.
      OrderedItem i;

      // Call the Deserialize method to restore the object's state.
      i = (OrderedItem) serializer.Deserialize(reader);

      // Write out the properties of the object.
      Console.Write(
      i.ItemName + "\t" +
      i.Description + "\t" +
      i.UnitPrice + "\t" +
      i.Quantity + "\t" +
      i.LineTotal);
   }

i also notice most samples don't null objects after use
is it ok to just let scope take care of destroying reference?

thanks
mark
Click to expand...

I would have put the whole thing in a using statement, or at least
wrapped it in a try/catch, but yes, it is ok. The filestream will
close
itself when it is destroyed. In this case, since it isn't being
written
to, you aren't worried about flushing the data to disk anyway.

Matt
 
this example comes from
msdnhttp://msdn.microsoft.com/en-us/library/dsh84875.aspx
i notice they don't close filestream
is that ok?

private void DeserializeObject(string filename)
{
Console.WriteLine("Reading with Stream");
// Create an instance of the XmlSerializer.
XmlSerializer serializer =
new XmlSerializer(typeof(OrderedItem));
// Reading the XML document requires a FileStream.
Stream reader= new FileStream(filename,FileMode.Open);

// Declare an object variable of the type to be deserialized.
OrderedItem i;

// Call the Deserialize method to restore the object's state.
i = (OrderedItem) serializer.Deserialize(reader);

// Write out the properties of the object.
Console.Write(
i.ItemName + "\t" +
i.Description + "\t" +
i.UnitPrice + "\t" +
i.Quantity + "\t" +
i.LineTotal);
}

i also notice most samples don't null objects after use
is it ok to just let scope take care of destroying reference?

thanks
mark
Click to expand...

I would have put the whole thing in a using statement, or at least
wrapped it in a try/catch, but yes, it is ok. The filestream will
close
itself when it is destroyed. In this case, since it isn't being
written
to, you aren't worried about flushing the data to disk anyway.

Matt

i see, thanks
that explains why they closed it in the write method but not the read
mark
 
this example comes from msdn
http://msdn.microsoft.com/en-us/library/dsh84875.aspx
i notice they don't close filestream
is that ok?

private void DeserializeObject(string filename)
{
Console.WriteLine("Reading with Stream");
// Create an instance of the XmlSerializer.
XmlSerializer serializer =
new XmlSerializer(typeof(OrderedItem));
// Reading the XML document requires a FileStream.
Stream reader= new FileStream(filename,FileMode.Open);

// Declare an object variable of the type to be deserialized.
OrderedItem i;

// Call the Deserialize method to restore the object's state.
i = (OrderedItem) serializer.Deserialize(reader);

// Write out the properties of the object.
Console.Write(
i.ItemName + "\t" +
i.Description + "\t" +
i.UnitPrice + "\t" +
i.Quantity + "\t" +
i.LineTotal);
}
Click to expand...

No - it is not OK.

reader.Close should be called at the bottom or it should
be opened with the using statement (which will cause
Dispose to be called which will close the file).

Otherwise the file could be kept open for a long time,
using unmanaged ressources and locking the file for
other users.
i also notice most samples don't null objects after use
is it ok to just let scope take care of destroying reference?
Click to expand...

Yes.

Setting refs to null will not do any good, will clutter the
code and some claim that it could even delay garbage collection - so
it should definitely be avoided.

Arne
 
this example comes from msdn
http://msdn.microsoft.com/en-us/library/dsh84875.aspx
i notice they don't close filestream
is that ok?

private void DeserializeObject(string filename)
{
Console.WriteLine("Reading with Stream");
// Create an instance of the XmlSerializer.
XmlSerializer serializer =
new XmlSerializer(typeof(OrderedItem));
// Reading the XML document requires a FileStream.
Stream reader= new FileStream(filename,FileMode.Open);

// Declare an object variable of the type to be deserialized.
OrderedItem i;

// Call the Deserialize method to restore the object's state.
i = (OrderedItem) serializer.Deserialize(reader);

// Write out the properties of the object.
Console.Write(
i.ItemName + "\t" +
i.Description + "\t" +
i.UnitPrice + "\t" +
i.Quantity + "\t" +
i.LineTotal);
}

i also notice most samples don't null objects after use
is it ok to just let scope take care of destroying reference?

thanks
mark
Click to expand...

This is bad.
You should understand what "unmanaged resource" is, and what a
close/dispose means to them.
Files, network connections, databases, graphics objects are examples of
unmanaged resources. They should be handled with special care. For
example, when you open a file, the OS will put a lock on it and others
have to wait until the lock is release in order to make modification to
it. Consider below code example,

using System;
using System.IO;

namespace MyNamespace
{
public class MyClass
{
public static void Main(string[] args)
{
OpenFile();

Console.ReadLine();
}

public static void OpenFile()
{
Stream reader = new FileStream("abc.txt", FileMode.Open);
//reader.Close();
}
}
}

If you run the above code, try renaming the file or make some
modification to it. Since you didn't explicitly close the stream, the OS
will hold the lock longer than it should be (the stream will eventually
close when the GC kicks in). Try uncomment the reader.Close() statement
and you'll see the difference.

As a best practice, enclose your unmanaged resource usage in a using
statement.
 
Arne Vajhøj said:
this example comes from msdn
http://msdn.microsoft.com/en-us/library/dsh84875.aspx
i notice they don't close filestream
is that ok?
[]
Click to expand...

No - it is not OK.

reader.Close should be called at the bottom or it should
be opened with the using statement (which will cause
Dispose to be called which will close the file).

Otherwise the file could be kept open for a long time,
using unmanaged ressources and locking the file for
other users.
i also notice most samples don't null objects after use
is it ok to just let scope take care of destroying reference?
Click to expand...

Yes.

Setting refs to null will not do any good, will clutter the
code and some claim that it could even delay garbage collection - so
it should definitely be avoided.

Arne
Click to expand...

Thanks Arne,
mark
 
It wasn't even very useful in VB, although most of us were told we should do
so.
Click to expand...

VB used reference counting not reachability like .NET and even
though reference was automatically decremented when ref
went out of scope, then going out of scope could be a lot later
than being done using it.

It probably became a rule cast in stone, because a huge
portion of VB developers never really understood COM.

To be a little cynical - that may even qualify them as
being smart - if I had the choice between learning to
set everything to nothing or learning IUnknown and IDispatch,
then I would pick the first any time.

Arne
 
Back
Top