Rabbitmq Channel.Dispose vs channel = null

Question

I have this type of code (pseudo):

IModel channel;
try
{
    channel = connection.CreateModel();
}
catch
{
    channel.dispose();
}

Sometimes, I get time-out exception from the channel.Dispose because of bad connectivity. What will happen if i'll just do channel = null;? Is it so wrong? will it stay alive in the rabbit with no way to reach it?

Answer 1

Your description of the problem is correct.

If channel is an unmanaged resource (and most likely it is, because it has a dispose method), then by setting the variable channel to null, you are throwing the reference to it away. So in other words, you are just cutting the only way to communicate with this resource in memory, but anyway it will still reside in memory and take some space (even after forgetting its address in memory by setting the reference to null). This is exactly what is called memory leak.

In case your object is not created frequently and is relatively small, this will not hurt (of course this is a bad design), but as soon as your program grows and creates many memory leaks you will be in a bad situation and you memory will start to run out.

Catching exceptions in Dispose is also not good if you don't really pay attention, because it can lead to leaks also, but with additional difficulty in debugging.

In case you are sure that by retrying to dispose will work somewhen later, then in a catch block in Dispose implementation retry to call Dispose again. Again, you have to be careful here to not end up with a leak with debug difficulties (worse than the original problem).

Actually it is very bad that excpetions are thrown in Dispose, however, sometimes you cannot control 3rd party code and you have to deal with that exception carefully in your Dispose.

Just for your information, yet a better dispose implementation would be using this dispose pattern.

And a final word, which I guess you know. If this resource is unmanaged, then you need to call this dispose not in catch, but finally, without mentioning the possibility to wrap the resource with a using keyword.