Преимущества напористого программирования

Question

Какой смысл вкладывать утверждения в наш код? Каковы преимущества напористого программирования?

private void WriteMessage(string message)
{
    Debug.Assert(message != null, "message is null");

    File.WriteAllText(FILE_PATH, message);
}

Например, мы можем проверить переменную сообщения и сгенерировать здесь исключение. Почему я здесь использую assert? Или это неправильный пример, чтобы увидеть преимущества утверждений?

Answer 1

Они также поддерживают философию быстрого провала, объясненную в этой статье Джимом Шором.

Answer 2

Где некоторые люди пишут:

/*
 * This can never happen
 */

Гораздо практичнее написать:

assert(i != -1);

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

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

Answer 3

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

Answer 4

Я использую их, чтобы убедиться, что мне предоставлен допустимый зависимый класс. Например, в конструкторе DI вы обычно принимаете какой-то внешний класс, от которого зависит предоставление какого-либо действия или услуги.

так что вы можете утверждать (classRef! - null, "classRef не может быть null"); вместо того, чтобы ждать, пока вы передадите сообщение в classRef, и получите какое-то другое исключение, например, исключение: нарушение доступа или что-то столь же неоднозначное, что может быть не сразу замечено при просмотре кода.

Answer 5

Для отличного обсуждения утверждений (и многих других тем, связанных с построением кода), посмотрите Code Complete от Стива Макконнела. Он посвящает целую главу эффективному использованию утверждений.

Answer 6

Если существует заданное предварительное условие для метода, чтобы принять ненулевой параметр сообщения, то вы хотите, чтобы программа СБОЛА, как только предварительное условие не выполняется и источник ошибки должен быть неподвижная.

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

Answer 7

Очень полезно проверить наши предположения. Утверждения постоянно проверяют, что инвариант верен. Короче говоря, он используется для следующих целей:

• Позволяет реализовать отказоустойчивую систему.
• Это уменьшает распространение ошибки из-за побочных эффектов.
• Запрещает (вид проверки работоспособности) системы переходить в несогласованное состояние из-за пользовательских данных или последующих изменений кода.

Иногда я предпочитаю использовать assert_return (), когда мы не хотим использовать try / catch / throw.

private void WriteMessage(string message)
{
    assert_return(message != null, "message is null"); // return when false
    File.WriteAllText(FILE_PATH, message);
}

Я предлагаю assert_return () остановить приложение, сообщив об ошибке в тестовой сборке. А затем в производственной системе он должен регистрировать ошибки и ошибки и возвращаться из функции, говоря, что не может этого сделать.