I have a class that implements the interface IDisposable. My understanding is that when you have finished using the object (something like the line below) the Dispose method is called to make sure everything is cleaned up - is that correct?
myObj = null;
I also would like to know if an exception is thrown whether the Dispose method still gets called? Or should I just be using a 'using' block?
My understanding is that when you have finished using the object (something like the line below) the Dispose method is called to make sure everything is cleaned up - is that correct?
No, it is not correct. Setting an instance of an object to null will not call its Dispose method, you should do that explicitly when you're done with an object.
myObj.Dispose();// Im done with myObj!
This is often done by utilizing using
using(var myObj = new MyObject())
{
myObj.DoSomething();
} // Dispose automatically called.
The above ensures Dispose is called, even if an exception is thrown within the using block.
Dispose should be explicitly called if want to release the system resources used by this object at that particular moment . If we are not calling the Dispose , the system will take care of this at some point with Garbage Collector .
If an object implementes System.IDisposable then we will be able to call the dispose method on it.
Using will be converted in to try, finally block by CLR and the dispose method will be called the in the finally block to release the resources.
Check this link for all information you required like how system handles this and all Using Statement
Just copying the code from the mentioned link to make it more useful.
If you have some code like this
using (MyResource myRes = new MyResource())
{
myRes.DoSomething();
}
Then it get's automatically converted to
MyResource myRes= new MyResource();
try
{
myRes.DoSomething();
}
finally
{
// Check for a null resource.
if (myRes!= null)
// Call the object's Dispose method.
((IDisposable)myRes).Dispose();
}
Related
What is an alternate/better way I can safely dispose of the variables purge and factory in the following code?
public void Run( string XmlFragment ) {
XmlNode xmlNode = null;
try
{
xmlNode = Common.ConstructXmlNodeFromString(XmlFragment, "Params");
var list = DataList();
foreach (var item in list)
{
var factory = new PurgerFactory(item);
IPurger purge = factory.Purger;
purge.Purge();
purge = null;
factory = null;
}
Common.PurgeEmail(SuccessEmail());
}
catch (Exception ex)
{
string errorMessage = $"Purge Error: {ex.Message}. {Environment.NewLine} Stack Trace: {ex.StackTrace}";
Common.PurgeEmail(FailEmail(errorMessage));
}
}
As I think you know, C# has a garbage collector. So for normal objects that don't access an unmanaged resource, just letting the garbage collector clean them is fine.
If you want to deterministically close a managed resource the primary paradigm is inheriting from IDisposable and a using statement. This will call the Dispose function upon exiting the code block of the using statement.
If you otherwise want to clean stuff up, but you don't care when it happens you can use ~(MyType). This is called when the GC does a GC cycle, this is called the Finalizer. I personally haven't encountered a use-case for this vs IDisposable. But if you just want to make sure say a file, or otherwise is deleted when this email object is Garbage Collected, then it might be a good use case for you.
Your code doesn't indicate whether purge or factory implement IDisposable. If they do, you would call
purge.Dispose();
factory.Dispose();
or use using which ensures that Dispose is called even if the method throws an exception:
using(var factory = new PurgerFactory(item))
{
// do stuff
} // factory is disposed.
What we don't need to do is set variables to null. An object gets garbage collected sometime after there are no longer any references to it. It's true that setting factory = null removes that reference to the object, but the same thing happens anyway when the variable goes out of scope. So it's redundant.
There's really no need to try to force that to happen sooner. It's not like the object will get garbage collected the instant there are no more references to it, so we don't worry so much about that.
In this case, the variables are both declared within the foreach loop, so the references go out of scope immediately after each iteration of the loop. In other words, they already go out of scope right at the point when you're setting them to null.
That's part of what's awesome about .NET. Imagine if we had to set every reference variable to null. We'd need try/catch everywhere to make sure it happened. It would be as if every single object was disposable. What a nightmare. Instead it's handled for us in most normal scenarios so that we don't have to think about it or clutter our code with it.
Using C#.NET 4.0
My company's application makes use of a resource locker to keep records from being edited simultaneously. We use the database to store the start time of a lock as well as the user who acquired the lock. This has led to the following (strange?) implementation of dispose on the resource locker, which happens to be called from a destructor:
protected virtual void Dispose(bool disposing)
{
lock (this)
{
if (lockid.HasValue)
{
this.RefreshDataButtonAction = null;
this.ReadOnlyButtonAction = null;
try
{
**Dictionary<string, object> parameters = new Dictionary<string, object>();
parameters.Add("#lockID", lockid.Value);
parameters.Add("#readsToDelete", null);
Object returnObject = dbio2.ExecuteScalar("usp_DeleteResourceLockReads", parameters);**
lockid = null;
}
catch (Exception ex)
{
Logger.WriteError("ResourceLockingController", "DeleteResourceLocks", ex);
}
finally
{
((IDisposable)_staleResourcesForm).Dispose();
_staleResourcesForm = null;
}
}
}
}
I am concerned about the bolded section we because have been logging strange "Handle is not initialized" exceptions from the database call. I read elsewhere that it is not safe to create new objects during Finalize(), but does the same rule apply to dispose()? Are there any possible side effects that accompany creating new objects during Dispose()?
which happens to be called from a destructor
That's the real problem. You cannot assume that the *dbio2" object hasn't been finalized itself. Finalization order is not deterministic in .NET. The outcome would look much like you describe, an internal handle used by the dbase provider will have been released so a "Handle is not initialized" exception is expected. Or the dbio2 object was simply already disposed.
This is especially likely to go wrong at program exit. You'll then also have problem when the 2 second timeout for the finalizer thread, a dbase operation can easily take more.
You simply cannot rely on a finalizer to do this for you. You must check the disposing argument and not call the dbio2.ExecuteScalar() method when it is false. Which probably ends the usefulness of the destructor as well.
Dispose is just a method, like any other method. There are some conventions about things that it should/shouldn't do, but there's nothing from the system's perspective that is wrong with creating objects in a Dispose call.
Making a DB call is a bit concerning to be personally; I wouldn't expect such an expensive and error prone activity to be called in a Dispose method, but that's more of a convention/expectation. The system won't have a problem with that.
Yes, but I would not do so unless the object created is within the local scope of the method. IDisposable is an advertisement that this class has some resource (often an unmanaged resource) that should be freed when the object is no longer used. If your Dispose is being called by your finializer (ie you are not calling the destructor directly, but waiting for the GC to do it) it can be an indication that you should be calling it earlier. You never know when the C# destructor will run, so you may be unnecessarily tying up that resource. It could also be in indication that your class doesn't need to implement IDisposable.
In your case your are using object dbio2 which I assume represents your DB connection. However, since this is called from the destructor how do you know if your connection is still valid? You destructor could an hour after your connection has been lost. You should try to ensure that this Dispose is called while you know the dbio2 object is still in scope.
using(YourType yourObject = new YourType())
{
//Treatment on you object
//Exception occurs here
}
when we write this way, the garbage collector automatically disposes the object, but is exceptions occurs inside this will the garbage collector still dispose the object or I have to write something for it, I know this is a lame q but m really confused, thnx
please explain the treatment in different .net frameworks to make things crystal clear.
Yes, the using block will still call Dispose on an exception. See MSDN documentation.
The using statement ensures that Dispose is called even if an exception occurs while you are calling methods on the object.
Also another useful article Avoiding Problems with the Using Statement.
From MSDN Documentation
The using statement ensures that Dispose is called even if an
exception occurs while you are calling methods on the object. You can
achieve the same result by putting the object inside a try block and
then calling Dispose in a finally block; in fact, this is how the
using statement is translated by the compiler.
using (var object = new Object())
{
object.DoSomething();
}
equal with:
var object = new Object();
try
{
object.DoSomething();
}
finally
{
object.Dispose();
}
While programming over an existent class, I've noticed that someone has written something like this:
using(DisposableObject disp = new DisposableObject())
{
...
...
disp.Dispose()
}
And then I wonder: isn't the using block enough to dispose an object? Could be there any way Dispose() can be useful in such case?
Cause it doesn't make any sense to me...
In your case it is useless to use dispose inside using because when using statement's scope ends it automatically calls dispose. That's why you can only write objects which implements IDisposable Interface inside using brackets.
using(.......)
Moreover if there was any statement using disp object after disp.Dispose() it would give an error, because by then object would have been disposed, i.e. its memory has been released.
But beware
If dispose is last line before using scope ends then it is useless.
But it is not useless when there are more lines after dispose.
Yes, a using block is actually equivalent to and an alternative syntax for:
var d = new DisposableObject();
try
{
d.DoSomething();
}
finally
{
if(d != null)
((IDisposable)d).Dispose();
}
Note that it uses finally instead of something like 'catch'. The finally-clause will always be executed, even if there's an exception.
using is enough. There is no reason to call Dispose twice.
There are two reasons why you can use Dispose inside a using block:
you want to dispose the object before the using block ends. In this case the using block is a "safety net" that ensures you that your object will be disposed even if an exception happens. (using behaves like a try block which has a finally block in which your object is disposed)
calling Dispose makes more clear what you're doing. This is typical, i.e. of
transaction scopes:
using(TransactionScope ts=new TransactionScope)
{
...
if (cond)
{
ts.Complete();
}
else
{
ts.Dispose(); // makes it clear you're rolling back the transaction
}
}
This call to Dispose it's not neccesary, but it's "explanatory". It makes more obvous that the transaction is rolled back.
#Nikhil Agrawal is right. One thing I need mention is when you implement Idisposable interface, you should make sure it can be invoked many times. That's mean you should do some validation.
I have this class:
class Foo : IDisposable
{
SomeBigResource resource;
void UsingResource()
{
using(Bar bar = new Bar(SomeBigResource)
bar.doStuff();
}
void Dispose()
{
resource.Dispose();
}
}
void Function()
{
using (Foo foo = new Foo(new SomeBigResource))
foo.UsingResource();
}
The Bar object has exactly the same Dispose() function.
Will my SomeBigResource be released or is the GC smart enough to release it later on when the second using is done?
If both the Dispose methods in Foo and Bar calls Dispose on the SomeBigResource object, the method will be called twice. If the method is implemented correctly it will release the resources the first time and do nothing the second time.
What you have is a confusion of responsibility, where both objects take responsibility for calling Dispose on the SomeBigResource object. This is something that you want to avoid, as one object can't know if the other object still needs the resource, so you want to put the responsibility in one place only.
You should either make the Foo object responsible for the life cycle of the resource, or handle it outside of the objects completely. The latter makes more sense, as that's where you create the SomeBigResource instance:
using (SomeBigResource resource = new SomeBigResource()) {
using (Foo foo = new Foo(resource)) {
foo.UsingResource();
}
}
Your resource will be disposed twice.
The GC is completely unaware of IDisposables and the using statement.
Each using statement translates into a try / finally block with a Dispose() call in the finally block.
This is a normal method call which will always execute.
Therefore, the inner using statement in UsingResource() will dispose the resource, and then the outer using statement in Function() will dispose it again.
All IDisposable implementations should be idempotent (calling it a second time should do no harm).
Therefore, (assuming that SomeBigResource implements IDisposable correctly), your code should work fine.
Note, though, that with your class, an empty using block will throw a NullReferenceException, which is very wrong.
You should add a null check in your Dispose method.
This depends on the implementation of Bar.Dispose(). Assuming it has a similar implementation as Foo, then, yes, the release will occur early.
Take a look at the Dispose pattern guidance and this SO question. There are more corner cases than you may think of immediately.
I assume this line should read:
using(Bar bar = new Bar(resource))
If that's the case, then when bar is disposed, it should dispose of resource.
So, yes. When bar is disposed in UsingResource, it will dispose resource, so that if you attempt to use it later, it should throw an ObjectDisposedException. (Although in your simple example, that shouldn't happen.)