2009-07-10 4 views
17

Я не знаю, сколько бесчисленное количество раз я должен был написать код для проверки строковые аргументы:C#: Аргумент проверки: нулевые/пустые строки

public RoomName(string name) 
{ 
    if (string.IsNullOrEmpty(name)) 
    { 
     throw new ArgumentException("Cannot be empty", "name"); 
    } 
} 

Есть в любом случае, чтобы избежать этого? Есть ли какой-то атрибут или механизм дизайна за контрактом, чтобы избежать этого? Невозможно сказать:

public RoomName(NotNullOrEmptyString name) 
{ 

, не создавая этот тип?

+0

Вы можете найти эту ссылку на [Аргумент проверки с использованием атрибутов и перехвата метода] (http://www.codinginstinct.com/2008/05/argument- validation-using-attributes.html) полезно – Joe

ответ

7

Вы можете сделать это путем ввода кода с помощью атрибутов.

Другой вариант, чтобы сэкономить время кодирования, но по-прежнему дает вам много контроля, будет использовать что-то вроде CuttingEdge.Conditions. Это обеспечивает свободно интерфейс для проверки аргумента, так что вы можете написать:

name.Requires().IsNotNull(); 
1

Хотя вопрос был дан ответ некоторое время назад, я думал о той же проблеме в последнее время. Формализованные кодовые контракты (с автоматической проверкой или проверкой) кажутся хорошей идеей, но, как правило, их возможности проверки довольно ограничены, и для простых проверок, таких как проверка нулевой или пустой строки, требуется столько же кода (или более), чем старомодные проверки.

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

public class NonEmptyString : IComparable<NonEmptyString>, ... 
{ 
    private readonly string _value; 

    public NonEmptyString(string value) 
    { 
     if (value == null) 
     { 
      throw new ArgumentNullException("value"); 
     } 
     if (value.Length == 0) 
     {     
      throw NewStringIsEmptyException("value"); 
     } 
     _value = value; 
    } 

    public string Value 
    { 
     get { return _value; } 
    } 

    ... 
} 

public class NonWhiteSpaceString : NonEmptyString 
{ 
    .... 
} 

Конечно, проходя вокруг этих случаев не мешает вам от того, чтобы проверить, если они обнулить себя, но у него есть некоторые большие преимущества:

  • Вы не должны проверить на пустой или бело- пробелы снова и снова, которые могут быть подвержены ошибкам в ситуациях, когда строка проходит вокруг много.
  • Как и в моей реализации, проверка на нуль - это нечто иное, чем проверка пустого значения (или пробельного значения), потому что вы хотите бросить определенное исключение ArgumentNullException в первом случае и некоторое исключение ArgumentException во втором.
  • Он ясно сигнализирует об ограничении на значение строки, как и любой класс упаковки. На самом деле, если у вас есть строка, которая имеет какие-либо ограничения, и она передается по многим параметрам, я всегда рекомендую ее обернуть в класс, который инкапсулирует проверку и оставит остальную часть кода вне проблем. Хорошим примером этого являются строки, которые должны удовлетворять определенному регулярному выражению. Тем не менее, я отвлекаюсь от вопроса здесь ...
+1

Я думаю, вам нужно добавить отслеживание имени параметра в ваше решение. Это связано с тем, что большинство из них сбивает с толку, если вы вызываете 'frob (string foo, string bar)' с 'frob (null," значение ")' и получаем сообщение об ошибке 'System.ArgumentNullException: Значение не может быть нулевым. Имя параметра: value' вместо 'System.ArgumentNullException: Значение не может быть нулевым. Имя параметра: foo' –

Смежные вопросы