I love extension methods

No question in this post, just something you might put to good use too:

I got sick of this code that uses Configurationmanager all over the place

Code:

---

bool b;
string s = ConfigurationManager.AppSettings["SomeKey"];
if (s != null)
  b = Convert.ToBoolean(s);

---

So first I made this shorter by creating an alias for ConfigurationManager.AppSettings.

NameValueCollection settings = ConfigurationManager.AppSettings;

and then you can call

Code:

---

strings s = settings["SomeKey"];
if (s != null) b = Convert.ToBoolean(s);

---

But this still has the conversion functions and the checking for null all over the place.
So I created a generic extension method for NameValueCollection which is the type of AppSettings.

Code:

---

        public static T Get<T>(this NameValueCollection cm, string index, T def)
        {
            T ret = def;

            string s = cm[index];

            if (s != null)
                ret = (T)Convert.ChangeType(cm[index], typeof(T));

            return ret;
        }

---

and now you can just call

Code:

---

bool b = settings.Get<bool>("SomeKey", false);

---

Hope you like it.

Cheers

I have a couple of problems with that.

1) Argument naming really needs to be more explicit. I find that 'def', particularly troubling. 'default' sounds and looks better. Also 'index' isn't the right choice. If you are hiding the AppSettings semantics you should mirror that in your arguments. 'key' or 'name' looks better to me.

2) Your method doesn't check for invalid casts or format exceptions.

Extension methods have their uses. But you could have saved yourself some trouble by simply declaring and assigning the string s to "false", before using it.

EDIT: What I mean is something like this:

Code:

---

string s = ConfigurationManager.AppSettings["SomeKey"] ?? "false";
bool  b = Convert.ToBoolean(s);

---

I don't find your use of extension methods troubling. It's just that I personally took the view that I will want to use them only when I want to add functionality to an existing class. Also the above code, I find, is easier to maintain since it quickly reveals your intent where it is being applied. It will also avoid you testing for exceptions, except where required.

agree on the naming part (except that default cant be used, its a keyword)

disagree on the not catching exceptions part. Convert.ToBoolean throws an exception too if it cant be formatted so there's no difference there. So I put the exception handling on a higher level and only during program initialisation.

Quote:

---

Originally Posted by KIBO

Convert.ToBoolean throws an exception too if it cant be formatted so there's no difference there. So I put the exception handling on a higher level and only during program initialisation.

---

Hence why I said you don't have to handle exceptions, unless you need to. Because you are moving to a generic function, you'll have to handle exceptions in method code due to the generic nature of the function. It will not only help you against application user mistakes but will also be required to check against the calling code (mistakes you-yourself may make while coding a caller to the function). But within your calling code, if you don't use such a function and simply replace it with a more streamlined version of your code (as exemplified) you will be in control of any exception handling decisions. Whether or not the above code, for instance, requires any exception handling.