래핑 된 객체의 예외를 다시 throw

Question

ConcurrentSet<T>을 구현하는 데 ConcurrentDictionary<TKey, TValue>을 사용합니다.

public class ConcurrentSet<T> : ISet<T> 
{ 
    private readonly ConcurrentDictionary<T, byte> collection; 
} 

ConcurrentDictionary<TKey, TValue>은 null 키가있는 쌍을 포함 할 수 없습니다.

// summary, param, returns... 
/// <exception cref="ArgumentNullException"> 
///  <paramref name="item" /> is null. 
/// </exception> 
public bool Add(T item) 
{ 
    // This throws an argument null exception if item is null. 
    return this.collection.TryAdd(item, 0); 
} 

그래서, 내가해야합니까

if (item == null) 
    throw new ArgumentNullException("item", "Item must not be null."); 

return this.collection.TryAdd(item, 0); 

을해야 또는한다 I,

try 
{ 
    return this.collection.TryAdd(item, 0); 
} 
catch (ArgumentNullException) 
{ 
    throw new ArgumentNullException("item", "Item must not be null."); 
} 

을 또는한다 I,

try 
{ 
    return this.collection.TryAdd(item, 0); 
} 
catch (ArgumentNullException x) 
{ 
    // I know, but I don't want to preserve the stack trace 
    // back to the underlying dictionary, anyway. 
    throw x; 
} 

을 또는

try 
{ 
    return this.collection.TryAdd(item, 0); 
} 
catch (ArgumentNullException) 
{ 
    // The thrown exception will have "key", instead of 
    // "item" as the parameter's name, in this instance. 
    throw; 
} 

이 작업을 수행하는 올바른 방법은 무엇입니까? 당신의 예에서

Answer 1

당신이해야 할 일은 클래스를 문서화하고자하는 것에 달려 있습니다. null 항목을 추가하려는 시도가 명시되지 않은 방식으로 실패 할 수 있음을 문서화하려면 간단히 직접 전화를 걸고 예외를 버블 링하십시오. 을 item과 동등한 ParamName과 함께 반환하고 null 키를 수신했을 때 ConcurrentDictionary의 동작에 의존하기를 원하지 않는다고 문서화하려면 ConcurrentDictionary으로 전달하기 전에 인수를 확인해야합니다. 당신은 당신의 코드가 item 동일한 ParamName와 함께 ArgumentNullException를 던질 것이라는 점을 문서화하고 싶은데 인수의 유효성을 검사 ConcurrentDictionary에 의존하고 ArgumentException, 을 던져 기꺼이하고 경우 성능이 중요하다면, 또 다른 가능성은 다음과 같습니다

try 
{ 
    return this.collection.TryAdd(item, 0); 
} 
catch (ArgumentNullException ex) 
{ 
    if (ex.ParamName == "key" && item == null) 
     throw new ArgumentNullException("item", "Item must not be null."); 
    else 
     throw; 
} 

이 코드는 매개 변수가 null이 아닌 시나리오에서 매개 변수 유효성 검사를위한 추가 비용을 피하지만 (그럼에도 불구하고 99.9999 %의 시간이 필요합니다) 그럼에도 불구하고이 매개 변수가 매개 변수 유효성 검사의 원본이라고 주장 할 것입니다. ArgumentNullException과 같은 예외가 예상되는 이유로 발생하는 경우 ConcurrentDictionary의 버그로 인해 null이 아닌 항목을 추가 할 때도 내부에서 호출하는 메서드에 null 인수가 실수로 전달되는 경우 위 코드는 원래 예외 스택 추적이 손실되지 않도록합니다. 또 다른 가능성이있을 수 있습니다 :

if (ex.ParamName == "key" && item == null) 
     throw new ArgumentNullException("item", "Item must not be null."); 
    else 
     throw new UnexpectedException(ex); // Probably a custom type 

item 이외의 이유로 ConcurrentDictionary.Add에서 ArgumentNullException 이스케이프가 null 인 경우, 이러한 예외가 하지가 ArgumentNullException을 기대할 수있는 코드에 의해 체포해야한다는 것을 기본 개념 너에게서.

Answer 2

그들은 모두 너무 유사하지만 나는 첫 번째 옵션과 함께 갈 것 :

if (item == null) 
    throw new ArgumentNullException("item", "Item must not be null."); 

그것은 catch을 필요로하고 컴팩트 보이는하지 않는 한. 또한 요구 사항이 변경 될 경우 조건을 확장 할 수 있으며, 그와 같은

if (item==null || item.Name == null) 
    throw... 

Answer 3

내가 함께 갈 것 같은 코드의 더 많은 라인을 추가하지 않습니다 중 하나이

public bool Add(T item) 
{ 
    // This throws an argument null exception if item is null. 
    return this.collection.TryAdd(item, 0); 
} 

또는이

if (item == null) 
    throw new ArgumentNullException("item", "Item must not be null."); 

return this.collection.TryAdd(item, 0); 

null이 있으면 수업에 신경 쓰는지 여부에 따라 다릅니다.

null 확인을 수행하는 유일한 이유는 null을 TryAdd으로 전달하지 않는 것이므로 검사를 거치지 않아도됩니다. TryAdd은 자체 검사를 수행하고 예외를 throw합니다.

null을 허용하는 다른 콜렉션을 사용할 수 있다고 생각하지만 콜렉션에 널 (null)이 없도록하려면, 자신을 점검해야합니다. 그 변화가 미래의 시점에서 일어날 경우, 이것은 당신을 보호 할 것입니다.

매개 변수의 유효성 검사는 항상 메소드가 수행하는 첫 번째 작업이어야합니다. 매개 변수가 유효하지 않으면 다른 작업을 수행 할 필요가 없습니다.

예외를 잡으려는 경우에만 예외를 catch해야합니다. 다시 던지거나 동등한 새로운 표현식을 만들려는 경우, 잡기가 쉽지 않습니다.

Answer 4

나는 당신이 무엇을 말하려합니까? 은이 아니라 원하는 효과에 따라 달라집니다. 오류를 삼키고 사용자에게 표시하지 않겠습니까? catch 상자에 오류를 다시 throw하지 말고 try-catch를 포함하십시오. 맞춤 오류 메시지를 원하십니까, Item == null 수표로 가십시오. 새로운 예외 인스턴스를 생성하는 데별로 사용하지 않으므로 어쨌든 예외가 발생합니다.

나머지는 간다. 오류를 로깅하지 않거나 특별히 업스트림을 처리하지 않으면 오류를 다시 잡아서 다시 포착 할 필요가 없습니다. 그렇지 않으면, 이것은 개인적인 스타일과 당신이 커스텀 에러 메시지를 원하는지 아닌지에 달려 있습니다.

내 즐겨 찾기는 아마도 사용자 정의 오류 메시지로 확인하는 Item == null인데, 사용자 지정 오류 메시지가 좋기 때문입니다. 그 (것)들이 저를 위해 더 유용하다는 것을 찾아 내고, 그러나 이 방법이라고 주변에 실수 취급이다는 것을 확인하십시오, 그래야 더 이상 처리되지 않는 예외를 일으키는 원인이되지 않는다.