using ( var sw = new StreamWriter ( file ) )
{
XmlSerializer xs = new XmlSerializer ( typeof ( T ) );
xs.Serialize ( sw, data );
sw.Close()
}
I know you don't have to call Dispose
but do you have to call the Close
method on sw
?
The using statement guarantees that the object is disposed in the event an exception is thrown. It's the equivalent of calling dispose in a finally block.
The using statement causes the object itself to go out of scope as soon as Dispose is called. Within the using block, the object is read-only and can't be modified or reassigned. A variable declared with a using declaration is read-only.
In C#, both scope and declaration space is defined by a statement block enclosed by braces. That means namespaces, classes, methods, and properties all define both a scope and a declaration space. As a result, scopes can be nested and overlap each other.
No! You don't have to. It's taken care of by "using"
The whole idea behind IDisposable is that classes which implement will do whatever is necessary for "reasonable" cleanup if the IDisposable.Dispose method is called. The exact action performed by Dispose may vary depending upon the state of an object, and may not always be the style of cleanup which is desired. For example, a command/transaction object may perform a rollback if it's disposed without first calling a "commit" method. This would restore the command/transaction to a "safe" state, but not necessarily the one that was intended.
Note also that error handling may be different in cases involving an explicit "close", a deterministic "dispose", or an non-deterministic "finalize" (resulting from the object being abandoned). It's clear semantically that a "close" operation which does not result in the closed object being in the correct state should throw an exception. It's less clear that a Dispose method should do so.(*) Some classes will throw from a failed dispose and others won't. If an object is abandoned and a problem occurs during finalize, few classes will provide any notification, since there's no good mechanism for dealing with it. If the "close" operation at the end of saving a document fails because someone pulled out their USB drive too soon, an application can inform the user that the document may not have saved, and the user can act accordingly. If the application abandons the file object so the "close" operation doesn't happen until some time later, by which point the USB drive has been removed, there's not really much the application can do to handle the error. In the former situation, the program could suggest that the user try again to save the document, but in the latter situation the document might be gone.
(*)If there's no exception pending when a Dispose occurs, and Dispose can't perform its required cleanup, it's pretty clear that an exception should be thrown. On the other hand, if an exception is already pending, throwing from Dispose will destroy all information the earlier exception held. My preferred style would be to use a Dispose(Exception Ex) method which will pass Ex as an inner exception if the Dispose fails, but without language support such a thing can only be supported with awkward syntax in vb.net, and with dubious behavior in C#.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With