using statement usage in C#

Question

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!

1. Your are asking two questions in one - it is actually not a recommended format on [SO]. 2. About first question - we do not know how your class is designed. Or are you asking whether you should dispose nested object or not? — Eugene Podskal, Apr 25 '15 at 11:59
It depends on how your class MyJob implements IDisposable.. Be sure you are following the correct pattern... [link](https://msdn.microsoft.com/en-us/library/ms244737.aspx) — Spencer Waz, Apr 25 '15 at 12:08
Related - http://stackoverflow.com/questions/3306245/dispose-on-nested-disposable-items. — Eugene Podskal, Apr 25 '15 at 12:10
I may be wrong, but I'm pretty sure there's no additional magic behind the `using` statement apart from being so called "syntactic sugar" that calls `IDisposable.Dispose` on the parameter after executing the enclosed code block. — Grx70, Apr 25 '15 at 12:11

Yuval Itzchakov · Accepted Answer · 2015-04-25T12:05:13.583

5

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.

edited Apr 25 '15 at 12:05

answered Apr 25 '15 at 11:58

Yuval Itzchakov

146,575
32
257
321

As the other answers say, if he calls Results.Dispose in the MyJob.Dispose method, then it will in fact be disposed, so the top part is only true if he doesn't explicitly dispose it in the MyJob object. – Ron Beyer Apr 25 '15 at 12:04
@RonBeyer You're right, I edited my answer just as you posted the comment :) – Yuval Itzchakov Apr 25 '15 at 12:05
I don't think that "you could decide" is the right wording. The pattern states pretty clearly that in the various `Dispose()` methods you **have** to dispose of disposable resources, meaning that `MyJob` must dispose of any `JobResult` it *has* (in a *has-a* relationship). There's no room for interpretation whatsoever in the actual documentation. – pid Apr 25 '15 at 12:12
@pid You're a programmer, and there is always room for self-interpretation. While you're right that it is the *recommended* approach, there is no one way to implement something, and his use-case may not fit the "has-a" relationship, so let's dispose of it. For example, take a look at stream wrappers, such as `GZipStream`, which accepts a `bool` to indicate whether to dispose the underlying stream, or leave it open. – Yuval Itzchakov Apr 25 '15 at 12:13

score 2 · Answer 2 · answered Apr 25 '15 at 12:03

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.

Ron Beyer · Answer 3 · 2015-04-25T13:18:23.677

2

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.

edited Apr 25 '15 at 13:18

answered Apr 25 '15 at 12:13

Ron Beyer

11,003
1
19
37

Two things. First, I wouldn't recommend implementing a finalizer, especially when we don't know from the OP's question whether these are un-managed resources. Second of all, even if you do end up implementing a finalizer, you should call `GC.SuppressFinalizer(this)` inside your `Dispose(bool disposing)` method. – Yuval Itzchakov Apr 25 '15 at 12:15
@YuvalItzchakov I edited to include the suppress finalize call, I missed it. I said below the post not to implement it unless some specific conditions are met, and the MSDN link shows a lot of good practices when implementing it. I was just showing a complete example assuming unmanaged resources without their own finalizers. – Ron Beyer Apr 25 '15 at 12:23
Don't get me wrong, I don't disagree about the finalizer issue, it is important to know that such a thing exists. I'm just saying that given the small amount of detail in the question, I wouldn't run off implementing a finalizer :) – Yuval Itzchakov Apr 25 '15 at 12:24

score 0 · Answer 4 · edited May 23 '17 at 10:26

0

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

edited May 23 '17 at 10:26

Community

1
1

answered Apr 25 '15 at 11:59

VladL

12,769
10
63
83

using statement usage in C#

4 Answers4