We Keep Coding

Order of disposal for base classes

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

Do this dispose the child objects or not?

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.

Is there any benefit to implementing IDisposable on classes which do not have resources?

In C#, if a class, such as a manager class, does not have resources, is there any benefit to having it : IDisposable?
Simple example:
public interface IBoxManager
{
int addBox(Box b);
}
public class BoxManager : IBoxManager
{
public int addBox(Box b)
{
using(dataContext db = new dataContext()){
db.Boxes.add(b);
db.SaveChanges();
}
return b.id;
}
}
Will there be any benefit in memory use when using BoxManager if it also implements IDisposable? public class BoxManager : IBoxManager , IDisposable
For example:
BoxManager bm = new BoxManager();
bm.add(myBox);
bm.dispose();//is there benefit to doing this?

There are only 2 reasons for implementing IDisposable on a type
The type contains native resources which must be freed when the type is no longer used
The type contains fields of type IDisposable
If neither of these are true then don't implement IDisposable
EDIT
Several people have mentioned that IDisposable is a nice way to implement begin / end or bookended operations. While that's not the original intent of IDisposable it does provide for a very nice pattern.
class Operation {
class Helper : IDisposable {
internal Operation Operation;
public void Dispose() {
Operation.EndOperation();
}
}
public IDisposable BeginOperation() {
...
return new Helper() { Operation = this };
}
private void EndOperation() {
...
}
}
Note: Another interesting way to implement this pattern is with lambdas. Instead of giving an IDisposable back to the user and hoping they don't forget to call Dispose have them give you a lambda in which they can execute the operation and you close out the operation
public void BeginOperation(Action action) {
BeginOperationCore();
try {
action();
} finally {
EndOperation();
}
}

There won't be a scrap of difference between the disposable and non-disposable version if you don't explicitly make use of the Dispose() method.

While your code wouldn't benefit from implementing IDisposable, I can't agree with other opinions here that state that IDisposable is only meant to (directly or indirectly) free native resources. IDisposable can be used whenever the object needs to perform clean up task at the end of it's lifetime span. It's extremely useful together with using.
A very popular example: in ASP.NET MVC Html.BeginForm returns an IDisposable. On creation, the object opens the tag, when Dispose is called it closes it. No native resources involved, yet still a good use of IDisposable.

No, there will be no benefit if you don't do something useful like releasing unmanaged resources that your class might hold in the Dispose method.

One major point of confusion, which may not be applicable in your case but arises often, is what exactly constitutes a "resource". From the perspective of an object, an unmanaged resource is something which an outside entity () is "doing"(*) on its behalf, which that outside entity will keep doing--to the detriment of other entitites--until told to stop. For example, if an object opens a file, the machine which hosts the file may grant that object exclusive access, denying everyone else in the universe a chance to use it unless or until it gets notified that the exclusive access isn't needed anymore.
(*) which could be anything, anywhere; possibly not even on the same computer.
(**) or some way in which the the behavior or state of an outside entity is altered
If an outside entity is doing something on behalf of an object which is abandoned and disappears without first letting the entity know its services are no longer required, the outside entity will have no way of knowing that it should stop acting on behalf of the object which no longer exists. IDisposable provides one way of avoiding this problem by providing a standard means of notifying objects when their services are not required. An object whose services are no longer required will generally not need to ask any further favors from any other entities, and will thus be able to request that any entities that had been acting on its behalf should stop doing so.
To allow for the case where an object gets abandoned without IDisposable.Dispose() having been called first, the system allows objects to register a "failsafe" cleanup method called Finalize(). Because for whatever reason, the creators of C# don't like the term Finalize(), the language requires the use of a construct called a "destructor" which does much the same thing. Note that in general, Finalize() will mask rather than solve problems, and can create problems of its own, so it should be used with extreme caution if at all.
A "managed resource" is typically a name given to an object which implements IDisposable and usually, though not always, implements a finalizer.

No, if there are no (managed or unmanaged) resources there is no need for IDisposable either.
Small caveat: some people use IDisposable to clean up eventhandlers or large memory buffers but
you don't seem to use those
it's a questionable pattern anyway.

From my personal experience (confirmed with discussion and other posts here) I would say, that there could be a situations where your object use massive amount of events, or not massive amount but frequent subscriptions and unsubscription from the event which sometimes leads to that the object is not garbage collected. In this case I in Dispose unsubscribe from all events my object subscribed before.
Hope this helps.

IDisposable is also great if you want to benefit the using () {} syntax.
In a WPF project with ViewModels, I wanted to be able to temporarily disable NotifyPropertyChange events from raising. To be sure other developers will re-enable notifications, I wrote a bit of code to be able to write something like:
using (this.PreventNotifyPropertyChanges()) {
// in this block NotifyPropertyChanged won't be called when changing a property value
}
The syntax looks okay and is easily readable. For it to work, there's a bit of code to write. You will need a simple Disposable object and counter.
public class MyViewModel {
private volatile int notifyPropertylocks = 0; // number of locks
protected void NotifyPropertyChanged(string propertyName) {
if (this.notifyPropertylocks == 0) { // check the counter
this.NotifyPropertyChanged(...);
}
}
protected IDisposable PreventNotifyPropertyChanges() {
return new PropertyChangeLock(this);
}
public class PropertyChangeLock : IDisposable {
MyViewModel vm;
// creating this object will increment the lock counter
public PropertyChangeLock(MyViewModel vm) {
this.vm = vm;
this.vm.notifyPropertylocks += 1;
}
// disposing this object will decrement the lock counter
public void Dispose() {
if (this.vm != null) {
this.vm.notifyPropertylocks -= 1;
this.vm = null;
}
}
}
}
There are no resources to dispose here. I wanted a clean code with a kind of try/finally syntax. The using keyword looks better.

is there any benefit to having it : IDisposable?
It doesn't look so in your specific example, however: there is one good reason to implement IDisposable even if you don’t have any IDisposable fields: your descendants might.
This is one of the big architectural problems of IDisposable highlighted in IDisposable: What your mother never told you about resource deallocation. Basically, unless your class is sealed you need to decide whether your descendants are likely to have IDisposable members. And this isn't something you can realistically predict.
So, if your descendants are likely to have IDisposable members, that might be a good reason to implement IDisposable in the base class.

Short answer would be no. However, you can smartly use the nature of the Dispose() executement at the end of the object lifecycle. One have already gave a nice MVC example (Html.BeginForm)
I would like to point out one important aspect of IDisposable and using() {} statement. At the end of the Using statement Dispose() method is automatically called on the using context object (it must have implemented IDisposable interface, of course).

There one more reason that no one mentioned (though it's debateful if it really worth it):
The convension says that if someone uses a class that implement IDisposable, it must call its Dispose method (either explicitly or via the 'using' statement).
But what happens if V1 of a class (in your public API) didn't need IDisposable, but V2 does? Technically it doesn't break backward compatibility to add an interface to a class, but because of that convension, it is! Because old clients of your code won't call its Dispose method and may cause resources to not get freed.
The (almost) only way to avoid it is to implement IDisposable in any case you suspect that you'll need it in the future, to make sure that your clients always call your Dispose method, that some day may be really needed.
The other (and probably better) way is to implemet the lambda pattern mentioned by JaredPar above in the V2 of the API.

IDisposable Question

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

Best practices for handling IDisposable

I have a class hierarchy, each member of which may create IDisposable objects.
I added a List<IDisposable> property to the base class in this hierarchy, to which I add any disposable objects on creation. The root Dispose method iterates through this list and calls Dispose for each item in its list and clears the list. In the application, I explicitly call the top object's Dispose method, causing disposal to cascade through the hierarchy.
This works, but is there a better way? Am I unwittingly duplicating some functionality already present in the framework?
(Note - the objects in question have a lifetime that precludes just wrapping them in a using block or disposing of them in the same methodwhere they are created.)
Edit
Just for clarification - I'm only keeping those objects around that need to be kept. Some are disposed of in the same method where they are created, but many are used in such a way that this isn't possible.

No that is correct. IDisposable is designed to free up unmanaged resources and should be called as soon as possible after you have finished with the instance. It's a common misconception that this is unnecessary, or that the finailizer will do this automatically when the object is garbage collected. It does not.
The correct pattern for IDisposable is here, and included below for quick reference.
public class Resource : IDisposable
{
// Dispose() calls Dispose(true)
public void Dispose()
{
Dispose(true);
GC.SuppressFinalize(this);
}
// NOTE: Leave out the finalizer altogether if this class doesn't
// own unmanaged resources itself, but leave the other methods
// exactly as they are.
~Resource()
{
// Finalizer calls Dispose(false)
Dispose(false);
}
// The bulk of the clean-up code is implemented in Dispose(bool)
protected virtual void Dispose(bool disposing)
{
if (disposing)
{
// free managed resources
}
// free native resources here if there are any
}
}

So long as you implement the disposable pattern correctly (as described here), this method is fine.
As far as I know, only using statements have special support for IDisposable - there isn't anything in the framework that replicates what you are doing.

If you're talking about arbitrary IDisposable objects, I don't believe it exists.
The System.ComponentModel.Container class implements cascading Dispose, but requires the elements to implement IComponent. If you control your IDisposable objects you could make them implement IComponent - it only requires implementing a single property Site that can return null.

Sounds like a situation where the visitor pattern could be appropriate. Although I never understand the claim that it extends your classes and leaves them unchanged, because I only know examples where classes should have an AcceptVisitor method or the like. BTW, it's not a pattern I like because it is complex and tends to clutter code.

If one object will create many other IDisposable objects and maintain ownership of them throughout its existence, the pattern you describe can be a good one. It may be enhanced by having your class implement method "T RegDispos<T>(T thing) where T:IDisposable;" which will add a disposable to the list and return it. One can thus take care of the creation and cleanup of a resource in the same statement, by replacing a statement like "someField = someDisposType.CreateThing();" with "someField = RegDispos(someDisposType.CreateThing());".
If your class doesn't expose a public constructor (requires outsiders use factory methods), and if you're either using vb.net or are willing to use thread-static fields, you can even combine initialization and cleanup with declaration (e.g. "var someField = RegDispos(someDisposType.CreateThing());"). For this to be safe, the constructor must be invoked within a try/catch or try/finally block that can call Dispose on created sub-objects if construction fails. Because field initializers in C# don't have access to constructor parameters (a weakness in the language, IMHO) the only way to implement such a pattern is to have a factory method create the list and put it into a thread-static variable which can then be read by a static RegDispos method.