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
So first I made this shorter by creating an alias for ConfigurationManager.AppSettings.
string s = ConfigurationManager.AppSettings["SomeKey"];
if (s != null)
b = Convert.ToBoolean(s);
NameValueCollection settings = ConfigurationManager.AppSettings;
and then you can call
But this still has the conversion functions and the checking for null all over the place.
strings s = settings["SomeKey"];
if (s != null) b = Convert.ToBoolean(s);
So I created a generic extension method for NameValueCollection which is the type of AppSettings.
and now you can just call
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));
Hope you like it.
bool b = settings.Get<bool>("SomeKey", false);
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:
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.
string s = ConfigurationManager.AppSettings["SomeKey"] ?? "false";
bool b = Convert.ToBoolean(s);
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.
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.
Originally Posted by KIBO