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
Related
Is Close() same as Dispose() or using statement. Is it necessary to call using statement even if Close is called?.
I know before disposing of an object, close should be called, so we close the resource and may it available to Dispose.
https://msdn.microsoft.com/en-us/library/aa355056(v=vs.110).aspx
says Close is same as Dispose.
Is Close() same as Using statement?
No it is not.
Should you call Close() after a using?
No, it will break due to access to the disposed object.
Should I call Close() before exiting the using block?
It's complicated. If the IDisposable interface is implemented correctly: no. Otherwise: possibly.
Close() has no relation to IDisposable interface, see: https://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx
using only applies to IDisposable inherited objects, see: https://msdn.microsoft.com/en-us/library/yh598w02.aspx
Thus:
Close() and Dispose() may not considered to be related in any way.
When the IDisposable interface is correctly implemented, you may assume all clean-up necessary will be carried out. This implies an internal call to a Close() method would be carried out. This means that an explicit call to Close() should not be necessary.
The other way round; when a object is of type IDisposable and exposes a Close() method, a call to Close() will not be sufficient to properly dispose/clean-up the object. Dispose() must still be called, you can do this directly, or through the using statement.
You can also let the garbage-collector handle the Dispose() call for you (if its correctly implemented, see: Proper use of the IDisposable interface) But this is considered bad-practice, since you need to rely on a proper implementation and have no direct control over the GC timing.
Please note, a reason to implement a Close() function, is usually to give a developer a way to reuse the object. After calling Dispose() the object is considered to be marked for finalization and may not be used any more.
The using pattern is useful because it includes a try ... finally ... that will protect against exceptions...
If you do:
FileStream fs = null;
try
{
fs = File.OpenRead("MyFile.txt");
}
finally
{
if (fs != null)
{
fs.Close();
}
}
then in this case it would be nearly equivalent (because the Stream.Close() calls the Dispose(true))
BUT it is still "wrong"... You use using for IDisposable classes unless you have a very very good reason (there are some reasons for not doing it... Sometimes the lifetime of an object is very very difficult to track. In that case it is normally ok to no Dispose() it.).
The concept of a pattern is that it should become part of you... If you try to skirt from a pattern, then before or later you'll forget about it... And for what? For writing MORE lines that are MORE error-prone?
Not necessarily. I can write a class that has a Close and a Dispose method that aren't related.
class Foo : IDisposable
{
public void Close() { DoBar(); }
public void Dispose() { DoBaz(); }
}
I was trying to find all classes in C# which implement Close(). For example Socket, StreamReader, StreamWriter class in C# contains Close() method for closing resources. Moreover, I noticed that some class implements IDisposable. Do all classes which contain Dispose() also contain Close().
That rule violation is trying to tell you that a class you initialized in the try implements IDisposable, and you don't have any code that calls the Dispose to reclaim its unmanaged resources. Classes that implement IDisposable are effectively "notifying you" that they need to be explicitly cleaned up. It's a very common pattern in .Net.
You could do something like:
SomeClassThatImplementsIDisposable x = null;
try
{
x = new SomeClassThatImplementsIDisposable();
//--> call methods on x...
}
finally
{
x.Dispose();
}
...but, what's far more common is to use a using block:
using ( var x = new SomeClassThatImplementsIDisposable() )
{
//--> call methods on x...
}
...which causes the compiler to build a try/finally block out of your using block.
So...it's not a Close method you should be concerned about. When you get the rule violation, you should do one of the two things above (preferably the latter by convention).
Further, you don't really need to care about all classes that have some method. You just need to run your static analysis, and it will tell you when you've not cleaned things up. You'll ultimately become very familiar with this pattern.
I have some doubts regarding the using statement:
I have a class called
MyJob which is Disposable. Then i also have a property on MyJob JobResults that is also Disposable.
MY code:
using (MyJob job = new MyJob())
{
//do something.
FormatResults(job.JobResults)
}
public string FormatResuls(JobResuts results)
{
}
MY First question is: In this case after the using block are both MyJob and MyJob.Results disposed or only MyJob and NOT MyJob.Results?
I am also performing parallel processing w.r.t Tasks in C#:
Tasks allTasks = List<Tasks>
try
{
foreach(Task t in allTasks)
{
// Each tasks makes use of an IDisposable object.
t.Start();
}
Task.WaitAll(allTasks);
}
catch(AggregateExecption aex)
{
/// How do I ensure that all IDisposables are disposed properly if an exception happens in any of the tasks?
}
My second q, in the code above, what is the proper way to ensure to dispose off objects correctly when handling exceptions in tasks?
Sorry if my questions are too naive or confusing, as i am still trying to learn and understand C#.
Thanks guys!
are both MyJob and MyJob.Results disposed or only MyJob and NOT
MyJob.Results?
That is subjective to the implementation of your Dispose method. As we haven't seen it in your question, I'll assume that you aren't currently disposing your Result property in MyJob.Dispose, hence it will be the latter.
As only MyJob is wrapped in a using statement, and again assuming it does nothing to your Result property, it will be disposed as opposed to Results, which isn't wrapped in a using statement.
You could decide that MyJob, as it encapsulates your Result property, is responsible for the disposable of it as well. If you decide so, you can dispose Results in MyJobs.Dispose.
what is the proper way to ensure to dispose off objects correctly when
handling exceptions in tasks?
If the delegate which is passed to the Task is wrapped in a using statement, you are safe, since using will transform your code to a try-finally block, if an exception occurs in your using block, the finally block will still run yourObject.Dispose.
Only MyJobs is disposed. For other properties, you need to understand object ownership: who owns the object should be responsible (in general) to dispose of it. A property implementing IDisposable could be used by other instances, so you can only dispose of it if you are the one who created it and there no other references to it, or the class fails gracefully if it knows that it has been disposed of.
There are a lot of good answers here but one thing remains. If you want to be assured that your object is properly disposed because it uses unmanaged resources, you should implement a destructor in your object, like:
class MyJob : IDisposable
{
private bool _disposed = false;
protected virtual void Dispose(bool disposing)
{
if (!_disposed)
{
//Dispose unmanaged resources and any child disposables here
}
}
void Dispose()
{
this.Dispose(true);
GC.SuppressFinalize(this);
}
~MyJob()
{
//ONLY use if you have unmanaged resources that DO NOT
//implement their own finalizers.
Dispose();
}
}
However, it is recommended that you DO NOT use a finalizer (destructor) unless you are finalizing a type with unmanaged resources that does not include its own finalizer.
See https://msdn.microsoft.com/en-us/library/b1yfkh5e.aspx for best practices on implementing IDisposable.
1) The best way is to dispose JobResults inside of MyJob's Dispose() methode. Otherwise it's not disposed on it's own
2) I would implement the finally part, go through every object and dispose it. But in most cases you donät need to do that read this
When a derived class overrides Dispose should the base class Dipose be called first before the derived class disposes of any local resources?
The reason I ask is because someone on our team is saying yes for every scenario, I'm trying to work out if this is good idea or just 'cargo cult' programming, I don't have a strong view either way.
Before:
public override void Dispose()
{
base.Dispose();
if (!_isDisposed)
{
_isDisposed = true;
if (_foo != null)
{
_foo.Dispose();
}
}
}
After:
public override void Dispose()
{
if (!_isDisposed)
{
_isDisposed = true;
if (_foo != null)
{
_foo.Dispose();
}
}
base.Dispose();
}
Note: I'm not looking for how to implement the basic dispose pattern but more clarification from peoples experiences.
"It depends"
You can't have a hard-and-fast rule for this, because the order you need to call dispose will depend on the implementation of the classes.
Sometimes you might want it at the start, sometimes at the end, and sometimes in the middle. Most of the time, it probably won't matter.
Generally speaking, people seem to call it first (in the absence of any other reason to call it at a different time).
One reason to lean towards calling it first is that then the derived class has a chance to do special stuff afterwards if it needs to.
You should think about the consequences of the different approaches. In most cases, the IDisposable objects owned by the base class will be independent of those owned by the derived class, and the order of disposal won't matter, provided none of the Dispose methods throws an Exception (*).
If it's critical to release an IDisposable resource, you could consider using try/finally to ensure all Dispose methods are called - but this isn't universally done. For example, the System.Component.Container class manages and disposes multiple IDisposable objects, but makes no attempt to ensure they are all disposed if an exception is thrown.
(*) It's perfectly legitimate for Dispose to throw: for example a FileStream might attempt to flush data to a network resource that's no longer available during Dispose.
Dispose object in the reverse order to create. So firstly is created base class, so it should be dispose in the end, and so on...
I have two classes, say class MyFirstClass and MyAnotherClass , MyAnotherClass is implementing IDiposable interface.
public class MyFirstClass
{
public string xyz{get;set;} ..... and so on
}
public class MyAnotherClass : IDisposable
{
private readonly MyFirstClass objFc = new MyFirstClass();
public static void MyStaticMethod()
{
var objOfFirstClass = new MyFirstClass();
// something with above object
}
public void MyNonStaticMethod()
{
// do something with objFc
}
#region Implementation of IDisposable
.... my implementations
#endregion
}
Now I have one more class where I am calling MyAnotherClass , something like this
using(var anotherObj = new MyAnotherClass())
{
// call both static and non static methods here, just for sake of example.
// some pretty cool stuffs goes here... :)
}
So I would like to know, should I worry about the cleanup scenario of my objects? Also, what will happen to my ObjFC (inside non static) and the objOfFirstClass (inside static).
AFAIK, using will take care of everything...but i need to know more...
objOfFirstClass is a local variable in a method. It will be eligible for garbage collection once the method is exited. It won't be disposed as such because it doesn't implement IDisposable.
objFc will be eligible for garbage collection when its parent object goes out of scope. Again, this is nothing to do with disposing it.
Dispose/IDisposable is used when there is clean up other than simple memory management to be done. The CLR handles cleaning up the memory for you using garbage collection. using is a nice way of ensuring that an object implementing IDisposable has its Dispose method called when you have finished with it - but if all you are after is memory management, you don't need to use it.
IDisposable indicates that an object is using resources other than managed memory; for example, file handles. The Dispose method is supposed to handle the clean-up of these resources (and that's what your implementation should do).
Any CLR-native object (e.g. those in your example) is garbage collected by the CLR when no more references to it exist (more specifically, by a mechanism called the garbage collector or GC); IDisposable is unnecessary in these cases.
In order to make use of IDisposable you have to call Dispose yourself (or use using, which is just syntactic sugar). It isn't called automatically by the GC.
There is not any magic behind IDisposable except that using calls the Dispose method.
As the class MyFirstClass does not implement IDisposable, there is no need to worry about instances of this class - they should not have anything to dispose.
If you have fields or variables that need to be disposed, you have to call Dispose. Additionally, you should implement a destructor that calls the Dispose method, as the reference proposes:
~MyClass() {
Dispose(false);
}
Where the boolean parameter specifies that fields should not be disposed, in this case. For details, see the linked msdn page.
IDispose disposes the class MyAnotherClass. This means that local variables of the MyFirstClass object are pointing to nothing. Therefore, they are reclaimed once the garbage collector runs.