2010-04-27 5 views
2

이 코드는 멤버가 이미 동일한 매개 변수 유형으로 정의되어있는 컴파일러 오류를 생성합니다.모호한 일반 제한 T : 클래스와 T : struct

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>(); 
     } 
    } 

깨끗한 해결 방법이 있습니까?

답변

3

오버로드 확인에는 일반 유형 제약 조건을 사용할 수 없지만 실제로는 오버로드 된 메서드가 필요하지 않습니다.

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

아, 나는 그대로 코드를 복사 한 그러나 이 같은 일반 Exception을 삼키지 마십시오 : 그냥 null 대신 default를 사용합니다. 실제로 예외가 발생할 수 있다는 점을 제외하고는 캐치하십시오. 이 코드가 우연히 OutOfMemoryException 또는 BadImageFormatException 인스턴스를 삼키는 것을 원하지는 않습니다.

+0

위시 예외에 대한 설명에 +2 할 수 있습니다. 방금 동료의 코드 일부를 디버깅하는 데 도움이되었습니다. 빈 캐치 (예외) 블록으로 흩어졌습니다. – Josh

+0

질문에 대한 좋은 답변입니다! –

+0

나는 일반적으로 모든 예외를 삼키지 않는다. 이것은 간단한 설정 속성 읽기 코드 였고, 메모리 부족 예외가 어디에서 던져 질 필요가 있는지를 확실히 알았지 만 왜 BadImageFormat에 대해 걱정할 것인가? 이 코드가 어떤 이유로 든 실패 할 경우 app 도메인을 중지하거나 중단하지 않겠지 만 메모리가 부족한 경우 확실히 좋은 도메인입니다. – Maslow