Showing posts with label C#. Show all posts
Showing posts with label C#. Show all posts

Tuesday, February 10, 2015

How to use a dictionary wisely

A dictionary is a touchy object - if you try to access a non-existant key, you get an exception. If you try to add an item using the Add() method which already exists in the dictionary - you get an exception. So, particularly in a multi-threaded environment, it is worth knowing some dictionary tricks
1. If you want to retrieve an item which may not be in the dictionary, use TryGetValue() method. This way you access the dictionary only once, but accomplish 2 things - you get the item if it exists, or safely know that it doesn't. The alternative - using ContainsKey() method and then accesing the item directly using its key - is not as good, because it envolves accessing the dictionary twice - once to check if the key exists, and second to get the item. And, if the item has been removed between these two actions - you get an exception on the second action of retrieving the item.
2. When you want to add an item to the dictionary, don't use the Add() method, use the indexer. Add() throws an exception if the item already exists, and usually (not always) this is not desirable. So, do this: dict[key] = value; This way, if the item exists, it is silently overriden.

Also note, in multi-threading environment which includes any add/remove operations, any access to the dictionary, including read operations, must be protected with a lock, as Dictionary is not thread-safe and a read operation which happens at the same time as an add/remove operation may encounter an exception. In any multi-threading context, consider using ConcurrentDictionary class.

Adam Porat is a senior c# developer at Travolutionary.

Sunday, August 26, 2012

Why WCF always gives CommunicationObjectFaultedException?

I have been frustrated regarding WCF - it always seemed to give the same obscure exception:
CommunicationObjectFaultedException - The communication object cannot be used because it is in the Faulted state

Finally I found out why.

Actually WCF usually throws clear exceptions. You just have to use it right.
I have been using WCF proxys with a C# using statement. And here the trouble lies.
What the C# using statement does is this: it wraps up the using block in a try clause, and in the finally clause it disposes the object given in the using clause. In other words, it ensures the object gets disposed even if an exception occured inside the block.
This is very good for working with files, etc. But with WCF it is a problem. Why? because the WCF proxy's Dispose method actually calls the proxy's Close method. But this Close method has a catch: if the proxy is in a Faulted state, Close() throws the infamous exception CommunicationObjectFaultedException.
So what happens is this: you call a method on a service and get an exception. This puts the proxy in a faulted state. Then the using block calls Dispose on the proxy, and the CommunicationObjectFaultedException is thrown.
A WCF proxy in a faulted state still holds some resources. And to dispose of them, you need to call the proxy's Abort method. This method does not throw an exception if the proxy is in a faulted state.

So the recommended pattern to use a WCF proxy is this:

// Create the proxy object here
try
{
     proxy.MyMethod();
}
finally
{
    if (proxy != null)
    {
        if (proxy.State == System.ServiceModel.CommunicationState.Faulted)
        {
            proxy.Abort();
        }
        else
        {
            proxy.Close();
        }
    }
}




The writer is a .Net team leader at Niloosoft Hunter HRMS