Утверждайте по сравнению с, возвращают false? [закрытый]

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

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

Рассмотрите возможность использования исключения, когда «случилось что-то плохое» = что-то исключительное ...

Ваш "return false" также называется GuardClause - как объяснил Уорд Каннингем:

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

Если ваше защитное предложение имеет любую сложность, часто бывает полезно инкапсулировать с использованием BouncerPattern .

Как указывает Уорд, вы должны использовать утверждения, когда код может быть безопасно опущено . Если у вас есть ключевое слово assert на вашем языке, компиляторы часто удаляют утверждения из производственного кода.

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

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

IMHO, assert - это утверждение разработчика в среде отладки, что происходит что-то неожиданное (неправильное). Не все утверждения должны быть критическими, и разработчики должны размещать утверждения для реальных ошибок.

В режиме выпуска вам нужно вернуть false только тогда, когда ошибка критическая и нет смысла продолжать выполнение.

Используйте утверждение, когда что-то плохое никогда не должно произойти, если код работает правильно. Пример:

int div( int a, int b ) {
  assert( b != 0 );
  return a / b;
}

Здесь вызывающий код отвечает за то, чтобы div () никогда не вызывалась со вторым параметром, равным нулю. Если это так, ваш код находится в неизвестном состоянии и должен быть прекращен.

Используйте if () ... return, когда может произойти ошибка, которую можно устранить. Например, при открытии файла может произойти сбой, и программа должна быть обнаружена и устранена - сбой не переводит программу в неизвестное состояние.

Assertions are for quality control purposes only. Removing them must not alter the behaviour of your program (i.e. your program must not rely on assertions to handle anything at all). Use exceptions if something happened that should not happen, but can happen under bad circumstances - e.g. network connection lost. Use return values to indicate success when failure is also an option.

That really depends on language/runtime environment, and the nature of the error.

In general, the program cannot recover from assertion failures (i.e. it will crash). That may or may not be what you want.

If your environment supports exceptions, you could also use these, that allows you to handle the error if you want to, and will abort with a helpful message if you dont handle the error.

The "return false" thing is error prone (b/c people forget to check the return value), so I'd use it only if neither assert nor exceptions are available.

Зависит от того, что вы проверяете. В первом случае, если произошедшая неприятность нарушает контракт для вашего класса, генерируйте исключение, которое будет что-то значить для клиента. Если вернуть false, никто не узнает, что состояние неверное.

Simple answer is both, but the second is more important. The assert checks a design assumption, thus before calling fn() I would have pre-conditions, e.g. that a given resource might be available. The assert will typically do nothing in release code, though not necessarily. If it is important that your function, gn, require something be true to work correctly, it eithers uses the if statement and returns and error code, or throws an exception. Assert typically does nothing in release code and thus your function might crash in this situation.

See also the more detailed answers given to this question

I would use assert whenever something like a contract is broken. What do I mean by this: in math, division by zero is not defined. So the contract with the division function is broken. More on contract see the progromming language Eiffel.

In some cases I would then implement a second function that has additional parameter(s) with default values and handles the exception, like StrinToIntegerDef(string, default), that returns default when string does not convert to Integer.

Return false can be done in cases where normal execution of the program is not at stake.

I would prefer meaningful exceptions, at least of the form assert(condition, message), if the language allows for that.

Also, if there are several possibilities to fail, return some enum values instead of false.

Use assertions to mandate the function's preconditions (conditions that must hold true if the function is to have any meaning).