I love extension methods

This is a discussion on I love extension methods within the C# Programming forums, part of the General Programming Boards category; No question in this post, just something you might put to good use too:
I got sick of this code ...

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.

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.

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.