Should objects created by an IDisposable that reference their creator dispose of that creator?

Question

I have a class that implements IDisposable according to this pattern because it contains a reference to HttpClient. It looks something like this:

public class CustomServiceClient : IDisposable
{
  HttpClient client;

  // ...

  public ServiceCreatedEntity GetEntity()
  {
    // ...
  }

  ~CustomServiceClient()
  {
    this.Dispose(false);
  }

  private bool disposed = false;
  void IDisposable.Dispose()
  {
    if(!disposed)
    {
      this.Dispose(true);
      GC.SuppressFinalize(this);
      disposed = true;
    }
  }

  public void Dispose(bool disposing)
  {
    if(disposing)
    {
      // dispose managed resources
      client.Dispose();
    }

    // dispose unmanaged resources - this class has none
  }
}

public class ServiceCreatedEntity
{
  CustomServiceClient client;

  public ServiceCreatedEntity(CustomServiceClient client)
  {
    this.client = client;
  }

  // some functions that use client
}

I'm wondering if ServiceCreatedEntity should implement IDisposable and dispose of the CustomServiceClient. I expect that CustomServiceClient will generally have a longer lifetime than ServiceCreatedEntity, and I'm worried that a client will dispose of ServiceCreatedEntity and be confused as to why their CustomServiceClient has been disposed of as well. Any tips would be greatly appreciated!

Unsure if this helps, but this reminds me of [this question](http://stackoverflow.com/questions/1065168/does-disposing-streamreader-close-the-stream). TL,DR: "StreamReader, StreamWriter, BinaryReader and BinaryWriter all close/dispose their underlying streams when you call Dispose on them." [Also related](http://stackoverflow.com/questions/1862261/can-you-keep-a-streamreader-from-disposing-the-underlying-stream), TL,DR: If you leave the GC to it, it "will call Dispose(false) which will not dispose the underlying stream.". Just to give you an idea of similar situations in .NET — tnw, Jun 30 '14 at 19:32
@tnw - I thought about that. I suppose I could provide documentation to my users advising them only to dispose of the `ServiceCreatedEntity` if they are done with the client, as well. But the difference here is that StreamReaders/Writers/etc. are created explicitly with the new operator (RAII and all that), so the creator is expected to "own" the object, whereas the `ServiceCreatedEntity` is instantiated and returned by the `CustomServiceClient`, which would indicate that perhaps the creator does not own it. — Andrew Gaspar, Jun 30 '14 at 20:24

score 1 · Answer 1 · answered Jun 30 '14 at 19:33

1

it's more of a question of what creates what... the creator should (typically) handle the teardown in a request oriented world.

answered Jun 30 '14 at 19:33

T McKeown

12,971
1
25
32

score 0 · Answer 2 · answered Jun 30 '14 at 19:34

ServiceCreatedEntity should not dispose the client, but if it has a dependency on the client it doesn't hurt to include a IsDisposed property or Disposing event on the client so that ServiceCreatedEntity can verify that the client is not disposed before using it, or just have CustomServiceClient throw an error if being used after disposal.

score 0 · Answer 3 · edited May 23 '17 at 10:32

I'm confused as to why CustomServiceClient has a method that returns ServiceCreatedEntity and yet ServiceCreatedEntity takes CustomServiceClient as a parameter in its constructor.

Generally, if an object is passed in, it should not be disposed in that object. If an object creates an IDisposable it should itself implement IDisposable and dispose of it. For any other circumstances (such as an IoC container, or something fancy), consider the lifespan of the object and when it will be disposed.

Take a look at this question for more information about IDisposable.

Should objects created by an IDisposable that reference their creator dispose of that creator?

3 Answers3