Какой синтаксис является наиболее плавным и привлекательным для подтверждения правильности параметров в C #?

Это может быть в некоторой степени полезно:

Дизайн по контракту / C # 4.0 / без исключения ArgumentNullException

Вам следует ознакомиться с Контракты кода; они делают в значительной степени именно то, о чем вы просите. Пример:

[Pure]
public static double GetDistance(Point p1, Point p2)
{
    CodeContract.RequiresAlways(p1 != null);
    CodeContract.RequiresAlways(p2 != null); 
    // ...
}

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

public static void Copy<T>(T[] dst, long dstOffset, T[] src, long srcOffset, long length)
{
    Validate.Begin()
            .IsNotNull(dst, “dst”)
            .IsNotNull(src, “src”)
            .Check()
            .IsPositive(length)
            .IsIndexInRange(dst, dstOffset, “dstOffset”)
            .IsIndexInRange(dst, dstOffset + length, “dstOffset + length”)
            .IsIndexInRange(src, srcOffset, “srcOffset”)
            .IsIndexInRange(src, srcOffset + length, “srcOffset + length”)
            .Check();

    for (int di = dstOffset; di < dstOffset + length; ++di)
        dst[di] = src[di - dstOffset + srcOffset];
}

Я не уверен, что это лучший ответ, но он определенно интересен. Вот сообщение в блоге , от Рика Брюстера.

Я занялся именно этой проблемой несколько недель назад, подумав, что странно, как кажется, что библиотеки тестирования нуждаются в миллионе различных версий Assert, чтобы их сообщения были описательными.

Вот мое решение.

Краткое изложение - с учетом этого фрагмента кода:

int x = 3;
string t = "hi";
Assert(() => 5*x + (2 / t.Length) < 99);

Функция My Assert может распечатать следующую сводку того, что ей передано:

(((5 * x) + (2 / t.Length)) < 99) == True where
{
  ((5 * x) + (2 / t.Length)) == 16 where
  {
    (5 * x) == 15 where
    {
      x == 3
    }
    (2 / t.Length) == 1 where
    {
      t.Length == 2 where
      {
        t == "hi"
      }
    }
  }
}

Таким образом, все имена и значения идентификаторов, а также структура выражения могут быть включены в сообщение об исключении, без необходимости повторять их в строках в кавычках.

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

Подход этого парня позволяет вам написать следующее:

public class WebServer
    {
        public void BootstrapServer( int port, string rootDirectory, string serverName )
        {
            Guard.IsNotNull( () => rootDirectory );
            Guard.IsNotNull( () => serverName );

            // Bootstrap the server
        }
    }

Обратите внимание, что нет строки, содержащей «rootDirectory», и нет строки, содержащей «serverName» !! И все же его сообщения об ошибках могут содержать что-то вроде «Параметр rootDirectory не должен быть пустым».

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

И реализация довольно проста, а именно:

public static class Guard
    {
        public static void IsNotNull<T>(Expression<Func<T>> expr)
        {
            // expression value != default of T
            if (!expr.Compile()().Equals(default(T)))
                return;

            var param = (MemberExpression) expr.Body;
            throw new ArgumentNullException(param.Member.Name);
        }
    }

Обратите внимание, что здесь используется «статическое отражение», поэтому в узком цикле или в чем-то подобном вы можете захотеть использовать подход Рика Брюстера, описанный выше.

Как только я опубликую это, я проголосую за Криса и ответ на другой вопрос SO. Это хорошая штука !!!

Используя мою библиотеку The Helper Trinity:

public void SomeMethod(string firstName, string lastName, int age)
{
    firstName.AssertNotNull("firstName");
    lastName.AssertNotNull("lastName");

    ...
}

Также поддерживает утверждение, что параметры перечисления верны, коллекции и их содержимое не являются null, строковые параметры не являются пустыми и т.д. Подробные примеры см. здесь в пользовательской документации. .

Вот мой ответ на проблему. Я называю это «Guard Claws». Он использует синтаксический анализатор IL из общих библиотек Lokad, но имеет более простой подход к формулировке фактических защитных предложений:

string test = null;
Claws.NotNull(() => test);

Вы можете увидеть больше примеров его использования в спецификациях .

Поскольку он использует реальные лямбды в качестве входных данных и использует анализатор IL только для генерации исключения в случае нарушения, он должен работать лучше на «счастливом пути», чем конструкции на основе выражений в других местах в этих ответах.

Ссылки не работают, вот URL: http://github.com/littlebits/guard_claws/

Общие библиотеки Lokad также имеет реализацию на основе синтаксического анализа IL, которая позволяет избежать дублирования имени параметра в строке.

Например:

Enforce.Arguments(() => controller, () => viewManager,() => workspace);

Выдает исключение с соответствующим именем параметра, если какой-либо из перечисленных аргументов имеет значение NULL. Он также имеет действительно изящную реализацию правил на основе политик.

e.g.

Enforce.Argument(() => username,    StringIs.Limited(3, 64), StringIs.ValidEmail);

Я бы предпочел просто оценить условие и передать результат, а не передавать выражение для оценки и параметр для его оценки. Кроме того, я предпочитаю иметь возможность настраивать все сообщение. Обратите внимание, что это просто предпочтения - я не говорю, что ваш образец неправильный, - но в некоторых случаях это очень полезно.

Helper.Validate( firstName != null || !string.IsNullOrEmpty(directoryID),
                 "The value for firstName cannot be null if a directory ID is not supplied." );

Не знаю, переносится ли эта техника с C / C ++ на C #, но я сделал это с помощью макросов:

    #define CHECK_NULL(x)  { (x) != NULL || \
           fprintf(stderr, "The value of %s in %s, line %d is null.\n", \
           #x, __FILENAME__, __LINE__); }
 

В этом случае, вместо того, чтобы использовать свой собственный тип исключения или действительно общие типы, такие как ApplicationException .. Я думаю, что лучше использовать встроенные типы исключений, специально предназначенные для этого использования:

Среди них .. System.ArgumentException, System.ArgumentNullException ...

Postsharp или другой AOP фреймворк.

Это применимо не везде, но может помочь во многих случаях:

Я предполагаю, что SomeMethod выполняет какую-то поведенческую операцию с данными «фамилия», «имя» и «возраст». Оцените свой текущий дизайн кода. Если три части данных требуют класса, поместите их в класс. В этом классе вы также можете поставить свои чеки. Это освободит SomeMethod от проверки ввода.

Конечный результат будет примерно таким:

public void SomeMethod(Person person)
{
    person.CheckInvariants();
    // code here ...
}

Вызов будет примерно таким (если вы используете .NET 3.5):

SomeMethod(new Person { FirstName = "Joe", LastName = "White", Age = 12 });

в предположении, что класс будет выглядеть так:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public int Age { get; set; }

    public void CheckInvariants()
    {
        assertNotNull(FirstName, "first name");
        assertNotNull(LastName, "last name");
    }

    // here are your checks ...
    private void assertNotNull(string input, string hint)
    {
        if (input == null)
        {
            string message = string.Format("The given {0} is null.", hint);
            throw new ApplicationException(message);
        }
    }

Вместо синтаксического сахара .NET 3.5 вы также можете использовать аргументы конструктора для создания объекта Person.

Для сравнения: это сообщение Мишко Хевери на Блог тестирования Google утверждает, что такая проверка параметров не всегда может быть хорошей вещью. В результате обсуждения в комментариях также поднимается несколько интересных моментов.