tags:

views:

56

answers:

1

This code generates a compiler error that the member is already defined with the same parameter types.

   private T GetProperty<T>(Func<Settings, T> GetFunc) where T:class
    {
        try
        {
            return GetFunc(Properties.Settings.Default);
        }
        catch (Exception exception)
        {
            SettingReadException(this,exception);
            return null;
        }
    }

    private TNullable? GetProperty<TNullable>(Func<Settings, TNullable> GetFunc) where TNullable : struct
    {
        try
        {
            return GetFunc(Properties.Settings.Default);
        }
        catch (Exception ex)
        {
            SettingReadException(this, ex);
            return new Nullable<TNullable>();
        }
    }

Is there a clean work around?

+3  A: 

Generic type constraints can't be used for overload resolution, but you really don't need an overloaded method for this. Just use default instead of null:

private T GetProperty<T>(Func<Settings, T> GetFunc)
{
    try
    {
        return GetFunc(Properties.Settings.Default);
    }
    catch (Exception exception)
    {
        SettingReadException(this,exception);
        return default(T);
    }
}

Oh, and I've copied your code verbatim, but please don't swallow the general Exception like this. Catch the specific exception that you actually expect might be thrown. You don't want this code inadvertently swallowing OutOfMemoryException or BadImageFormatException instances.

Aaronaught
Wish I could +2 for the comment about exceptions. I just recently helped a coworker debug some of his code and it was littered with empty catch (Exception) blocks
Josh Einstein
Good answer to the question!
Raj Kaimal
I don't typically swallow all exceptions, this was simple settings property read code, I certainly see where the out of memory exception needs to be thrown, but why would I be concerned about BadImageFormat? I don't care to stop or bring down the app domain if this code fails for any reason, but out of memory is certainly a good one.
Maslow
oh, and the reason I didn't want to return default(T) was the case of an int. I didn't want a 0 coming back as if it was the value.
Maslow
@Maslow: If you specify `Nullable<int>` instead of `int` as the type parameter then the default will come back as `null`. I'm not sure what your settings code read does, but if you need to catch anything more general than `ConfigurationException` then it's possible you're using exceptions as flow control, which will make your project more difficult to test and debug.
Aaronaught
I am attempting to fetch a value from the settings file, if it fails no matter the reason, I don't care I can use a default. If badImage or out of memory happens, this swallowing of not being able to get or set a property will not stop the next piece from throwing those exceptions. This is a non-critical section, and I don't want it to be able to cause unhandled exceptions.
Maslow
@Maslow: If those types of exceptions occur, your process is hosed. Continuing to run could cause serious problems - state corruption, data corruption, etc. It doesn't matter if the wrapped code is "not critical" - if you just swallowed an `ExecutionEngineException` then all sorts of *critical* code may go wrong afterward, which would not have gone wrong if you had left it alone because it would never have been executed in the first place. Don't catch `Exception`. Just don't. **Especially** in non-critical blocks where you could catch a specific, well-known exception instead.
Aaronaught