синтаксический сахар для метания с оператором нулевой Coalesce

Question

Давайте предположим, что мы хотим, чтобы бросить, если попытаться присвоить нуль к чему-то, что об этой уловке:

public static class ExceptionExtension 
    { 
     public static T Throw<T>(this Exception exc) 
     { 
      throw exc; 
     } 
    } 

, что мы можем использовать, например, как это:

return possibleNull ?? new Exception("Unspecified something....").Throw<string>(); 

Вы считаете, что это хорошая/худшая/бесполезная практика?

Answer 1

Это не имеет смысла для меня - не очень читаемо. Я бы ожидал, что второй аргумент оператора ?? будет того же типа possibleNull, чтобы не бросать экскремент.

Я предпочел бы видеть:

if(possibleNull == null) 
{ 
    throw new Exception("Unspecified something...."); 
} 

return possibleNull; 

Answer 2

Вы всегда можете вставить его в какой-то короткое название статической вспомогательный класс:

public static class Never 
{ 
    public static T Null<T>(T value) 
     where T : class 
    { 
     if (value == null) throw new ArgumentNullException(); 
     return value; 
    } 
} 

myClass.AProperty = Never.Null(somePotentiallyNullValue); 

Ваш другой пример не имеет особого смысла, Я бы предпочел назвать это «бесполезной» практикой.

Добавление немного «беглости» в классы-помощники обычно фокусируется на том, чтобы сделать вещи более читаемыми.

http://en.wikipedia.org/wiki/Fluent_interface

Answer 3

Это может быть лучше и более удобным для чтения, чтобы создать какой-то статический вспомогательный класс, который бросает Как это

public static class ThrowHelper 
{ 
    public static TException ThrowIfNull<TException>(object value) 
     where TException : Exception, new() 
    { 
     if (value == null) //or other checks 
     { 
      throw new TException(); 
     } 
    } 
} 

Answer 4

Я не считаю это хорошая практика.

Во-первых, сам метод расширения вводит метод для чего-то, к которому у нас уже есть ключевое слово: throw. Это может показаться странным. Он объявляет тип возврата, хотя он никогда не вернет значение, просто чтобы угодить компилятору в том контексте, где вы хотите его использовать. Ссылаясь на то, что уже указывали другие, это скорее «принцип наибольшего удивления».

Затем, глядя на то, как вы использовали этот метод, полученный код кажется не очень понятным для чтения. Еще хуже: вы можете использовать этот подход только в выражении, поэтому вы всегда будете иметь код, который каким-то образом использует объект (в вашем примере: просто верните его) и проверит его как null как побочный эффект в той же строке , Я предпочел бы делать явные проверки null и не смешивать с чем-то другим. Библиотека, подобная CuttingEdge.Conditions, может помочь уменьшить количество кода, который вы должны ввести для этого. Вы бы использовали его в своем примере таким образом

Condition.Requires(possibleNull , "possibleNull ").IsNotNull(); 
return possibleNull;