Related
Say I have the following:
public abstract class ControlLimitBase : IDisposable
{
}
public abstract class UpperAlarmLimit : ControlLimitBase
{
}
public class CdsUpperAlarmLimit : UpperAlarmLimit
{
}
Two Questions:
1.
I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
2.
How would I handle disposing of objects created in the CdsUpperAlarmLimit class? Should this also derive from IDisposable?
Dispose() is never called automatically - it depends on how the code is actually used.
1.) Dispose() is called when you specifically call Dispose():
myAlarm.Dispose();
2.) Dispose() is called at the end of a using block using an instance of your type.
using(var myAlarm = new CdsUpperAlarmLimit())
{
}
The using block is syntactic sugar for a try/finally block with a call to Dispose() on the object "being used" in the finally block.
No, IDisposable won't be called just automatically. You'd normally call Dispose with a using statement, like this:
using (ControlLimitBase limit = new UpperAlarmLimit())
{
// Code using the limit
}
This is effectively a try/finally block, so Dispose will be called however you leave the block.
CdsUpperAlarmLimit already implements IDisposable indirectly. If you follow the normal pattern for implementing IDisposable in non-sealed classes, you'll override void Dispose(bool disposing) and dispose your composed resources there.
Note that the garbage collector does not call Dispose itself - although it can call a finalizer. You should rarely use a finalizer unless you have a direct handle on unmanaged resources though.
To be honest, I usually find it's worth trying to change the design to avoid needing to keep hold of unmanaged resources in classes - implementing IDisposable properly in the general case is frankly a pain. It's not so bad if your class is sealed (no need for the extra method; just implement the Dispose() method) - but it still means your clients need to be aware of it, so that they can use an appropriate using statement.
IDisposable has one member, Dispose().
This is called when you choose to call it. Most typically that's done for you by the framework with the using block syntactic sugar.
I'm a little confused on when my IDisposable members would actually get called. Would they get called when an instance of CdsUpperAlarmLimit goes out of scope?
No. Its get called when you use using construct as:
using(var inst = new CdsUpperAlarmLimit())
{
//...
}//<-------- here inst.Dispose() gets called.
But it doesn't get called if you write this:
{
var inst = new CdsUpperAlarmLimit();
//...
}//<-------- here inst.Dispose() does NOT get called.
However, you can write this as well:
var inst = new CdsUpperAlarmLimit();
using( inst )
{
//...
}//<-------- here inst.Dispose() gets called.
The best practice recommend when you implement Dispose() method in non sealed class you should have a virtual method for your derived classes to override.
Read more on Dispose pattern here http://www.codeproject.com/KB/cs/idisposable.aspx
when using an IDisposable object, it's always good to use it this way:
using(var disposable = new DisposableObject())
{
// do you stuff with disposable
}
After the using block has been run, the Dispose method will be called on the IDisposable object. Otherwise you would need to call Dispose manually.
When someone calls .Dispose on it.
No, it already implements it through inheritance.
IDisposable is implemented when you want to indicate that your resource has dependencies that must be explicitly unloaded and cleaned up. As such, IDisposable is never called automatically (like with Garbage Collection).
Generally, to handle IDisposables, you should wrap their usage in a using block
using(var x = new CdsUpperAlarmLimit()) { ... }
this compiles to:
CdsUpperAlarmLimit x = null;
try
{
x = new CdsUpperAlarmLimit();
...
}
finally
{
x.Dispose();
}
So, back to topic, if your type, CdsUpperAlarmLimit, is implementing IDisposable, it's saying to the world: "I have stuff that must be disposed". Common reasons for this would be:
CdsUpperAlarmLimit keeps some OTHER IDisposable resources (like FileStreams, ObjectContexts, Timers, etc.) and when CdsUpperAlarmLimit is done being used, it needs to make sure the FileStreams, ObjectContexts, Timers, etc. also get Dispose called.
CdsUpperAlarmLimit is using unmanaged resources or memory and must clean up when it's done or there will be a memory leak
Which one do I call?
Is it necessary to call both?
Will the other throw an exception if I have already called one of them?
Close() and Dispose(), when called on a MemoryStream, only serve to do two things:
Mark the object disposed so that future accidental usage of the object will throw an exception.
Possibly1 release references to managed objects, which can make the GC's job a bit easier depending on the GC implementation. (On today's GC algorithms it makes no real difference, so this is a point for an academic discussion and has no significant real-world impact.)
MemoryStream does not have any unmanaged resources to dispose, so you don't technically have to dispose of it. The effect of not disposing a MemoryStream is roughly the same thing as dropping a reference to a byte[] -- the GC will clean both up the same way.
Which one do I call? Is it necessary to call both?
The Dispose() method of streams delegate directly to the Close() method2, so both do exactly the same thing.
Will the other throw an exception if I have already called one of them?
The documentation for IDisposable.Dispose() specifically states it is safe to call Dispose() multiple times, on any object3. (If that is not true for a particular class then that class implements the IDisposable interface in a way that violates its contract, and this would be a bug.)
All that to say: it really doesn't make a huge difference whether you dispose a MemoryStream or not. The only real reason it has Close/Dispose methods is because it inherits from Stream, which requires those methods as part of its contract to support streams that do have unmanaged resources (such as file or socket descriptors).
1 Mono's implementation does not release the byte[] reference. I don't know if the Microsoft implementation does.
2 "This method calls Close, which then calls Stream.Dispose(Boolean)."
3 "If an object's Dispose method is called more than once, the object must ignore all calls after the first one."
None of the above. You needn't call either Close or Dispose.
MemoryStream doesn't hold any unmanaged resources, so the only resource to be reclaimed is memory. The memory will be reclaimed during garbage collection with the rest of the MemoryStream object when your code no longer references the MemoryStream.
If you have a long-lived reference to the MemoryStream, you can set that reference to null to allow the MemoryStream to be garbage collected. Close and Dispose free neither the steam buffer nor the MemoryStream object proper.
Since neither Stream nor MemoryStream have a finalizer, there is no need to call Close or Dispose to cause GC.SuppressFinalize to be called to optimize garbage collection. There is no finalizer to suppress.
The docs for MemoryStream put it this way:
This type implements the IDisposable interface, but does not actually have any resources to dispose. This means that disposing it by directly calling Dispose() or by using a language construct such as using (in C#) or Using (in Visual Basic) is not necessary.
You can use the using block for this. It will automatically call Dispose when it goes outside of its scope.
Example:
using (MemoryStream ms = new MemoryStream())
{
// Do something with ms..
}
// ms is disposed here
Hope this helped.
Use using block so that your object is disposed if its implements IDisposable interface
the following code is Stream.Dispose from reflector as you can see, you don't need to close if you dispose (which is implicit when using using)
public void Dispose()
{
this.Close();
}
Which one do I call?
Any of them.
Is it necessary to call both?
No, either one is sufficient.
Will the other throw an exception if I have already called one of them?
No, disposable pattern declares that subsequent calls to Dispose don't cause negative effects.
Calling Close() will internally call Dispose() to release the resources.
See this link for more information:
msdn
Calling only Dispose() will do the trick =)
In .NET 3.5 (haven't checked other versions), methods are called in the following order when disposing a MemoryStream:
Stream.Dispose()
simply calls Close
Stream.Close()
calls Dispose(true), then GC.SuppressFinalize(this)
MemoryStream.Dispose(true)
sets _isOpen , _writable, and _expandable flags to false
Stream.Dispose(true)
closes async event if active
As a first solution, it's recommended to use using statements wherever possible. This is described here: http://msdn.microsoft.com/en-us/library/yh598w02.aspx
When the lifetime of an IDisposable object is limited to a single method, you should declare and instantiate it in the using statement. The using statement calls the Dispose method on the object in the correct way, and (when you use it as shown earlier) it also 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 cannot be modified or reassigned.
Coming to the question now, as others suggested in most .NET framework classes, there is no difference between Close() and Dispose() and it doesn't matter which of the two methods you call. You should call one but not both. However, there are exceptions.
There are exceptions; for example, System.Windows.Forms.Form and System.Data.SqlClient.SqlConnection have different behavior for Close() and Dispose().
For complete details, you can check here: https://blogs.msdn.microsoft.com/kimhamil/2008/03/15/the-often-non-difference-between-close-and-dispose/
This question already has answers here:
Closed 13 years ago.
Possible Duplicates:
Which is better, and when: using statement or calling Dispose() on an IDisposable in C#?
When should I use “using” blocks in C#?
using a using if statement?
Properly, how will I use a using statement? I have a tutorial open and i do not understand it. And i can see more than 1 different ways to implement. Which is correct or favored way?
The using statement is for any object which implements IDisposable.
using (var my_object = new IDisposableObject ())
{
//do my_object code here.
} //once the program reaches here, it calls my_object.Dispose();
Generally, this is used for objects with connections that manually need to be handled (closed) when the program is finished with them. For example, open connections to files and to the database.
The using statement will call Dispose even if there is an error in the code so it is akin to calling the Dispose method in a finally block of the try catch statement.
Example/Tutorial
It's a shorter syntax to make sure that dispose is called:
using (File f = File.Open("..."))
{
}
is the same as
File f;
try
{
f = File.Open("...");
}
finally
{
f.Dispose();
}
There are 2 fundamental ways you can use the using statement. As extracted from using Directive (C#) from MSDN.
Create an alias for a namespace (a using alias).
Permit the use of types in a namespace, such that, you do not have to qualify the use of a type in that namespace (a using directive).
Just to expand on Kevin's answer, a using statement effectively wraps your object instantiation in a try/finally block calling the object Dispose() method in the finally section i.e.
using(myObject m = new myObjecyt())
{
// Code here
}
is the same as
myObject m = new myObjecyt()
try
{
// Code here
}
finally
{
m.Dispose();
}
this can be verified by checking the MSIL.
The "Using" keyword helps do a certain thing to be done safely and clearly in .net. This is propertly disposing of certain objects. You may have learned how in .Net we have garbage collection, which means for many object we don't have to care about them when we are done using them. Other object however need to have a method called on them called Dispose. The best practice is that whenever an object has a Dispose method, then we should call that method when we're done with that object.
(They typically handle unmanaged resources. This means that it's using memory or other computer parts that are outside the control of the .NET runtime. So, when garbage collection reaches the discarded .Net object, it is unable to propertly let go of these resources. This can cause memory leaks and all kinds of other problems. A good example is an ADO.NET Connection object. Repeatedly not Disposing of your connection objects can cause DB problems.)
The Using keyword is also tied to this "Dispose" method. It's more accurate to say that when an object has a Dispose method, we either (A.) call .Dispose when we're done with it, or (B.) put our code that uses that object within a Using block. The Using block does several things for you:
When the code moves out of the block, the important Dispose method is automatically called for you.
More importantly, if there is an error in the code block, the Dispose method will still be called. This is why the using block is really helpful. Otherwise you have to put in a lot of error handling code.
The key is that for many of these object that have a Dispose method, error handling is particularly imortant. For a lot our code we don't need error handling; the consequences of an error happening are not really a problem. But for these IDisposable objects errors are often a problem, maybe a big problem. So, .Net provides a syntax for busy developers to add the most basic error handling and move on. Always start off with a Using block at least; maybe later you'll move to fancier error handling, but at least you've got this basic safety.
Here's a good explanation of the Using keyword.
In a class I am writing, I am using an object to set some of its properties in a custom class I am writing.
This is being done in the constructor, but the class has a Dispose() method.
I have never actually used an object in a constructor which has a Dispose() method/implements IDisposable. Should I wrap this in a using(...) statement or should I implement a destructor/finalizer?
My imagination has made me ask this: This class is part of a third party closed source API. How can I find out what needs to be disposed of?
Thanks
If your reference to the object is local to the constructor then just wrap it in a using statement.
If your reference to the object is a class member then your class should implement IDisposable as well, with it's Dispose() method calling Dispose() on the object.
Just to add in response to the other parts of your question:
You should generally only implement a finalizer where you are using unmanaged resources which might need to be cleaned up if your program terminates abnormally. Any managed objects will be tidied up by the GC at some point. Don't rely on a finalizer to dispose of any managed objects as you can't predict when it will be executed.
You don't need to care about what needs to be disposed of. You should trust that where a class implements IDisposable, it takes care of everything through that pattern. If it's badly coded then you may encounter problems, but I'd be optimistic in this case.
I'd always opt for wrapping IDisposables in a Using block where possible as I think it's neater than trying to call the Dispose() method explicitly.
if you don't need the object outside the constructor, why don't you use the using statement ?
If there is a special "destruction" code - using is not enough and you need to call it's disposal code from some place...
This question already has answers here:
What are the uses of "using" in C#?
(29 answers)
Closed 8 years ago.
Are there particular instances where I should (or shouldn't?) be using "using" blocks:
using(SomeType t = new SomeType()){
...
}
Some objects need some action to be taken when you have finished with them. Usually this is because the object uses some kind of resource that needs to be disposed of. For example, if you have a file object of class File, and this object opens a file from the file system, the file in the file system will need to be closed again.
If you just left the file object, and forgot to call file.Close() it wouldn't be cleaned up until the Garbage Collector (GC) ran and worked out nothing was still using the file object. When the Garbage Collector runs should be left to the Common Language Runtime (CLR) to decide. If the GC doesn't run for quite a while after you have finished with the file, the file could remain open potentially for a long time. This can pose a big problem if there are many file objects, or if something wants to open a file, but can't because the file object you left is still hanging around.
To solve this problem, C# has the IDisposable interface. This has one method called Dispose. Classes that require some cleanup implement this Dispose method. This gives you a standard way for cleaning up any objects that use resources. There are a lot of classes that need to have Dispose called. The problem with this is that code gets covered with calls to Dispose, and they are tricky to follow because the place where you new'ed the object and call Dispose to clean it up are different. So, you had to look around the code a lot and be very careful to check there were calls to Dispose in the right place.
To solve this problem C# introduced the 'using' keyword. You can put a 'using' keyword around where you new an object, and this ensures Dispose will be called on it for you. It guarantees that Dispose will be called whatever happens... even if there is an exception thrown within the body of the using statement.
So, you should use 'using' when you want to be sure an object that allocates resources will be cleaned up.
using can only be used for objects that are declared on the stack, i.e. in a function. It doesn't work for objects that are declared as members of a class. For them, you have to call Dispose yourself. You may have to implement Dispose in your class so that in can call Dispose on any member objects it has that require it.
Common objects that need using called on them are: Files, Database connections, Graphics objects such as Pen and Brush.
Sometimes it is also used when you want two operations to happen together. For example if you want to write a log statement when a block of code is entered and when it exits you could write a log class that you could use like this:
using( Log log = new Log("Doing stuff") )
{
// Stuff
}
The constructor for the log class could be made to write out the message, and the Dispose method could also write it out. Implement the finalizer (~Log) to assert if the Dispose method doesn't get called to ensure the 'using' is remembered around the 'new Log'.
When the SomeType class implements IDisposable.
Use using whenever the type implements IDisposable, unless you're going to wrap it in a try/catch block anyway, then you might as well (depending on what look you prefer) use a finally block.
I see plenty of other answers indicated when you should have a using statement. I want to address when specifically should not have a using statement:
If you need to use your object outside of the scope of the current function, don't have a using block. Good example are a factory method that returns a database connection or a method that needs to return a datareader. In either of those cases if you create your object with a using statement it would be disposed before the method returned, and therefore not usable outside the method.
Now, you still want to be sure that those objects are disposed, so you still might want a using statement somewhere. Just don't include it in the method where the object is actually created. Instead, you can wrap the function call itself in a using statement.
When SomeType implements IDisposable.
That is a clue to you the developer that SomeType uses unmanaged resources that need to be cleaned up.
Example:
using(SqlConnection MyConnection = new SqlConnection("Connection string"))
{
MyConnection.Open();
//...
// 1. SQLConnection is a type that implements IDisposable
// 2. So you can use MyConnection in a using statement
// 3. When using block finishes, it calls Dispose method of
// SqlConnection class
// 4. In this case, it will probably close the connection to
// the database and dispose MyConnection object
}
You can create your own objects that implements IDisposable:
public class MyOwnObjectThatImplementsIDisposable : IDisposable
{
//... some code
public void Dispose()
{
// Put here the code you want to be executed when the
// using statement finish.
}
}
So you could use an object of MyOwnObjectThanImplementsIDisposable type in a using statement:
using(MyOwnObjectThatImplementsIDisposable MyObject = new MyOwnObjectThatImplementsIDisposable)
{
// When the statement finishes, it calls the
// code you´ve writed in Dispose method
// of MyOwnObjectThatImplementsIDisposable class
}
Hope this helps
In this context the using statement is handy for types that implement IDisposable. When the code block exits the scope of the using statement, Dispose() is called implicitly. It's a good habit when working with objects you want to dispose immediately after use.
One specific instance in which you should be careful using a using block is with a WCF Service Client.
As noted in this MSDN article, wrapping a WCF client (which does implement IDisposable) in a using block could mask any errors which result in the client being left in a faulted state (like a timeout or communication problem). Long story short, when Dispose() is called, the client's Close() method fires, but throws and error because it's in a faulted state. The original exception is then masked by the second exception. Not good.
There are various workarounds out there, including one in the MSDN article itself. Others can be found at IServiceOriented and blog.davidbarret.net.
I prefer the last method, myself.
If you want a summary rule. Anytime an object using IDisposable where you would not have a catch, use using. Using, essentially, is this pattern:
try
{
//instantiate and use object
}
finally
{
//dispose object
}
If you do not need a catch, using can save you typing, which is a good thing.
The primary rule is:
* Use USING statement when objects implements IDisposable interface.
This interface provides the Dispose method, which should release the object's resources. If this method is not invoked then the object will stay in memory as long, as CLR wants to perform garbage collection. If the programmer use the USING statement then on the end the object will be disposed, and all resources will be free.
It is very important that all resources that are no longer in use be free as soon as possible.
For more information about it just visit this link: microsoft
Maybe it is worth mentioning that underlying reason for adding “using” lo C# languge is following: some resources can be scarce enough that it doesn’t make sense to wait for GC to call IDisposable. For example, DB connections. If you use try/catch/finally you won’t end up with a dangling connection, but connection will be left hanging until GC doesn’t kick in and this can take a while (if you do not close it explicitly). IF you use "using" (excuse the pun) you will release the connection immediately even if you forgot to close it and even if some exception occured inside the using block.
Another reason, as previous post mentions, is that programmers do not always use finally to clean up. If not using finally in the case of exception you end up with leaking resources…
One situation is when you want to do something at the beginning of a code block, and then undo it at the end of the block, unconditionally (even if there is a throw).
The ctor for the disposable class that you build (and call within the using) would perform the action, and then the Dispose method would undo that action. This is typically how I use it.
Other people has mentioned about "IDisposable" already.
But one of the caveats when using "using" statement is that,
any exceptions thrown within "using" will not be caught
even thought "SomeType" will be disposed regardless.
So in the following snippet,
using (SomeType t = new SomeType()){
throw new Exception("thrown within using");
}
throw new Exception("thrown within using"); should not be disregarded.
I would also add that use a using() statement if something implements IDispose and also if that something you want to dispose of holds on to NON-MANAGED resources like database connections and file handles.
If it's a normal object with say a List<T>, where T is like a Customer object that holds names and address, then you don't need to. The garbage collector is smart enough to manage this for you. But the garbage collector WILL NOT return connections to the connection pool or close file handles.