don't have to close filestream?

[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

 

[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

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

 

[mp]

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

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

 

[Arne Vajhøj]

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);
}

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?

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

 

[kndg]

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 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.

 

[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?
[]

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?

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

Thanks Arne,
mark

 

[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?
[]

This is bad.
You should understand what "unmanaged resource" is, and what a
close/dispose means to them. []

As a best practice, enclose your unmanaged resource usage in a using
statement.

Thanks kndg
mark

 

[Jeff Johnson]

i also notice most samples don't null objects after use

It wasn't even very useful in VB, although most of us were told we should do
so.

 

[mp]

It wasn't even very useful in VB, although most of us were told we should
do so.

at least it provided fodder for endless debate

 

[Arne Vajhøj]

It wasn't even very useful in VB, although most of us were told we should do
so.

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