Здравствуйте, Pzz, Вы писали:

>> #define VERIFY(f) ((void)f)

Pzz>Т.е., VERIFY, это ASSERT для идиотов, допускает без последствий проверки
Pzz>с побочными эффектами?

Идиоты как раз те, кто пишет

some_debug_assert(stream != NULL && ptr != NULL);
if (!stream || !ptr)
{
  ...
  return E_INVALIDARG;
}

или

{
  BOOL bRv = CloseHandle(...);
  ASSERT(bRv);
}

вместо

if (!some_verify(stream != NULL && ptr != NULL))
{
  ...
  return E_INVALIDARG;
}

или

VERIFY(CloseHandle(...));

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Почему нельзя отключать ASSERT-ы в релизе

СГ>В модульных (компонентных) расширяемых системах отключать ASSERT-ы в «релизе» нельзя. Это связано с тем, что для Вас-то, быть может эта система «релизная», а вот для клиента, который пишет для неё (и отлаживает) свои компоненты, она никакая не «релизная».

СГ>Фрагмент из хелпа к BlackBox:
СГ>Перевод на русский язык выполнен здесь.

Не вижу, как из этого фрагмента хэлпа следует вывод именно об ассёртах!

В релизе нельзя выключать, скажем, следующие проверки:

if (handle == INVALID_VALUE)
{
  // throw "grenade";
  return ERROR_INVALID_ARGUMENT;
}

Это и есть защита от ошибок за границами компонента, которая впрочем не может быть выключена и не должна быть выключена в релизе. Эти проверки никакого отношения к понятию Debug Assertion и вообще к условной компиляции Debug/Release не имеют Будет ли каждой такой проверке сопутствовать дебажный ASSERT(), дело программиста.

Здравствуйте, StanislavK, Вы писали:

SK>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Почему нельзя отключать ASSERT-ы в релизе

SK>Лучше использовать настраиваемые логи, тогда вопрос о том, что отключать в релизе, а что нет, просто не будет существовать, т.к. это можно будет сделать в любой момент.
Логи не спасают. В них смотрят только тогда, когда наблюдаемое поведение системы не соответствует ожиданиям. Более того, в них смотрят только тогда, когда наблюдаемое поведение системы включает вывод транспаранта "А-А-А-А! Случилась страшная фигня! Ничего не заработает, пока ты не посмотришь в логи!"
Логи по хорошему нужны для того, чтобы когда пользователь видит фразу "Невозможно выполнить операцию. Обратитесь к администратору", администратору было куда посмотреть для обнаружения дополнительной информации вроде "Попытка обратиться к ресурсу за пределами домена, отклонена в соответствии с установленной политикой безопасности". Потому, что администратор знает, что такое домен, ресурс, и политика безопасности. (А пользователь, естественно, не знает). Также логи полезны для того, чтобы когда администратор пишет в суппорт письмо о том, что "internal error 5412", ему было что приложить к этому письму, облегчая саппорту гадание на кофейной гуще. Потому, что саппорт знает, что такое "ResourceAcquisitionException at ...Utils.ResourceHelper.Copy(IResourceItem source, IResourceItem target, ResourceCopyFlags options)". (А админ, естественно, не знает).

Здравствуйте, GlebZ,

Всё наоборот.

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

GZ>1. Роль — программист который делает модуль. Для него ассерт как таковой информативен, поскольку несет в себе информацию о месте возникновения ошибки. Имея место, существует надежда что он может локализовать ошибку.

У него ассерты не срабатывают никогда, так как его модуль не содержит ошибок.

GZ>2. Роль — программист-клиент модуля. Для него ассерт по боку. Если он получит ассерт, то единственное что он поймет что где-то что-то у нас порой. Для него нужна более информативная ошибка о неверных параметрах, и каким образом он дошел до такой жизни.

Наоборот.
Для программиста второго модуля эти ассерты очень даже информативны, так как показывают, что он использовал первый модуль не так как положено. Он смотрит на полученное сообщение об ошибке (весь стек вызова со всеми полями объектов):


понимает, что это он — дурак и исправляет ошибку в своём модуле.

GZ>3. Роль — клиент.

А клиент, тут вообще не причем. Ему поставляется система без ошибок.

Здравствуйте, Sinclair, Вы писали:


СГ>>>Почему нельзя отключать ASSERT-ы в релизе
SK>>Лучше использовать настраиваемые логи, тогда вопрос о том, что отключать в релизе, а что нет, просто не будет существовать, т.к. это можно будет сделать в любой момент.
S>Логи не спасают. В них смотрят только тогда, когда наблюдаемое поведение системы не соответствует ожиданиям. Более того, в них смотрят только тогда, когда наблюдаемое поведение системы включает вывод транспаранта "А-А-А-А! Случилась страшная фигня! Ничего не заработает, пока ты не посмотришь в логи!"
S>Логи по хорошему нужны для того, чтобы когда пользователь видит фразу "Невозможно выполнить операцию. Обратитесь к администратору", администратору было куда посмотреть для обнаружения дополнительной информации вроде "Попытка обратиться к ресурсу за пределами домена, отклонена в соответствии с установленной политикой безопасности". Потому, что администратор знает, что такое домен, ресурс, и политика безопасности. (А пользователь, естественно, не знает). Также логи полезны для того, чтобы когда администратор пишет в суппорт письмо о том, что "internal error 5412", ему было что приложить к этому письму, облегчая саппорту гадание на кофейной гуще. Потому, что саппорт знает, что такое "ResourceAcquisitionException at ...Utils.ResourceHelper.Copy(IResourceItem source, IResourceItem target, ResourceCopyFlags options)". (А админ, естественно, не знает).

Ты о чем пишешь? О том, что плохо в логах и или о том, что иногда надо использовать вместо них ассерты?
Что касается ассертов, то ASSERT пользователю полездного скажет еще меньше, чем логи. Реальзация ассертов в большинстве случаев сильно страдает из-за своей неуниверсальности. Что ты будешь делать с с ассертами на сервере или в сервисе? В большистве случаев придется их выкинуть в релизной версии. Зачем они тогда вообще нужны? Самые сложные ошибки как раз в релизах. Надо забыть про ASSERTы и писать логи.

Здравствуйте, Pzz, Вы писали:

Pzz>Т.е., VERIFY, это ASSERT для идиотов, допускает без последствий проверки
Pzz>с побочными эффектами?

Я така дкмаю, что идиоты могут использовать и то и другое там, где не надо, но зачем нам думать об идиотах ?

Ассерт — это не обязательно вывод дебильного окошка с тремя вариантами. MSVC позволяет кастомизировать поведение ассертов (см. _CrtSetReportHook) — для сервера меня вполне устроит "int 3" вместо окошка или хотя бы запись в лог. Для более других компиляторов никто не запрещает перекрыть #define assert и делать в нём то что считаешь нужным. Я лично могу себе представить только одну ситуацию когда assert становится вредным — в случае написания какого-нибудь супертребовательного к реалтайму софта, где лишняя проверка не позволит влезть в требования по производительности. Но и в таком софте, подозреваю, мест где asssert поставить нет возможности вряд ли будет много.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Почему нельзя отключать ASSERT-ы в релизе

Все это напомнило мне давний фидошный флейм о том, нужна ли проверка на NULL в Сишной функции strlen. Я считаю, что данная конкретная проверка (на NULL в strlen) однозначно классифицируется как паранойя. .

McSeem2 wrote:
>
> СГ>*Почему нельзя отключать ASSERT-ы в релизе*
>
> Все это напомнило мне давний фидошный флейм о том, нужна ли проверка на
> NULL в Сишной функции strlen. Я считаю, что данная конкретная проверка
> (на NULL в strlen) однозначно классифицируется как паранойя. .

Мне приходилось иметь дело с компилятором, в рантайме которого вызов
функции memchr( s, c, 0 ) возвращал s + 1 (а не NULL) для любых значений
s и c.

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

AVC>В BlackBox, хелп к которому цитировал Губанов, ASSERT именно этим и занимается.
AVC>И как Вы правильно сказали, определенные требования к аргументам являются частью интерфейса компонента.
AVC> Поэтому отключать ASSERT в таких условиях нельзя. О чем опять же правильно написано в этом хелпе.

А что произойдет если компоненту передать неправильные аргументы?
Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.
Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
Вы считаете это правильным?

Здравствуйте, StanislavK, Вы писали:


SK>Ты о чем пишешь? О том, что плохо в логах и или о том, что иногда надо использовать вместо них ассерты?
Я пишу о том, что не надо сводить задачу обеспечения устойчивости к записи "если чо" в лог. Система должна обеспечить изменение наблюдаемого поведения в случае обнаружения внутренних сбоев. Достигается ли это ассертами или верифаями — неважно.
SK>Что касается ассертов, то ASSERT пользователю полездного скажет еще меньше, чем логи. Реальзация ассертов в большинстве случаев сильно страдает из-за своей неуниверсальности.
Я не вижу в ассертах никакой неуниверсальности.
SK> Что ты будешь делать с с ассертами на сервере или в сервисе? В большистве случаев придется их выкинуть в релизной версии.
Например, перезапущу сервис. Выкину исключение пользователю. Да мало ли что можно сделать, кроме как выкинуть в релизной версии?

Здравствуйте, MShura, Вы писали:

MS>А что произойдет если компоненту передать неправильные аргументы?
MS>Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.
MS>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
MS>Вы считаете это правильным?

Так ведь об этом-то и речь! Против неправильных данных передаваемых внутрь компонента стоит именно ASSERT. Это потому, что в интерфейсе к компоненту чётко прописано какие данные в него передавать можно. В функцию Sqrt можно передавать только неотрицательные числа. В качестве индекса массива можно использовать только число из соответствующего диапазона. Делить на ноль нельзя и т.д. Если программа всё-таки позволяет себе передавать отрицательное число в Sqrt, неправильный индекс массива, собирается разделить на ноль и т.д., то значит программа — ошибочна — получи ассертом по башке и иди ищи ошибку.

MS>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.

По инициативе-то оно по инициативе (первого) компонента, но по причине того, что другой (второй) компонент собирался неправильно использовать первый компонент. За это он (второй) получил по башке (от первого).

ASSERT — оборона одного компонента от других: тот кто собирается не правильно использовать этот компонент — жестоко поплатится за это.

К сожалению я тут учавствовал в разборках но не осознавал что речь идет не о C/C++. В этом случае я не могу ничего сказать, возможно что это применение оправданно и что означают "идеологически" асерты в этих языках/культурах не знаю.

Все мои дальнейшие рассуждения пойдут применительно C/C++ и похожих языках.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, MShura, Вы писали:

MS>>А что произойдет если компоненту передать неправильные аргументы?
MS>>Идеальный (с моей точки зрения) компонент вернет с помощью того или иного механизма ошибку, а клиент компонента вправе сам решать что ему делать в этом случае — падать или продолжать работать.
MS>>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.
MS>>Вы считаете это правильным?

СГ>Так ведь об этом-то и речь! Против неправильных данных передаваемых внутрь компонента стоит именно ASSERT. Это потому, что в интерфейсе к компоненту чётко прописано какие данные в него передавать можно. В функцию Sqrt можно передавать только неотрицательные числа. В качестве индекса массива можно использовать только число из соответствующего диапазона. Делить на ноль нельзя и т.д. Если программа всё-таки позволяет себе передавать отрицательное число в Sqrt, неправильный индекс массива, собирается разделить на ноль и т.д., то значит программа — ошибочна — получи ассертом по башке и иди ищи ошибку.

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

А асерты в данном случае должен свавить пользователь компонента, перед тем как подавать данные на компонент , и на возвращаемый результат.

Собственно Sqrt ведет себя вменяемо , на неправильные данные он реагирует исключением (или NAN), и уже дело программиста поставить ASSERT() на проверку аргумента перед отсылкой в Sqrt.


MS>>Оставляя ASSERT в компоненте программа аварийно завершится по инициативе компонента.

СГ>По инициативе-то оно по инициативе (первого) компонента, но по причине того, что другой (второй) компонент собирался неправильно использовать первый компонент. За это он (второй) получил по башке (от первого).

Это возможная ситуация при ОТЛАДКЕ приложения с использованием дебаговых библиотек.


СГ>ASSERT — оборона одного компонента от других: тот кто собирается не правильно использовать этот компонент — жестоко поплатится за это.

Это совершенно неправильное идеологически использование ASSERT, этим должны заниматься штатные средства обработки входных параметров (исключения, коды ошибок).

ASSERT был введен для совсем других целей, ASSERT это целая культура и идеология. Если вы проверяете входные параметры с помощью ASSERT , лучше заведите другой термин "VALIDATE_INPUT" и не путать одно с другим.

Здравствуйте, minorlogic, Вы писали:

M>Проверку неправильных данных обязана быть отработанна штатными средствами , и даже больше при тестировании "компонент" надо заваливать некоректными данными и убедиться , что он возвращает вменяемые ошибки.

Штатность зависит от языка и системы. Например, в языке Component Pascal — ASSERT — это самое что ни на есть штатное средство, часть языка, а не внешняя библиотека.

M>А асерты в данном случае должен свавить пользователь компонента, перед тем как подавать данные на компонент, и на возвращаемый результат.

На те данные которые он впихивает в компонент? Зачем? Если он попытается впихнуть в компонент неправильные данные, то компонент сам ругнётся — чего это мол вы тут в меня впихиваете отрицательные числа, когда в интерфейсе ко мне явно прописано, что я принимаю только неортицательные! Он просто должен впихивать в компонент правильные данные или не впихивать их вовсе.

M>Собственно Sqrt ведет себя вменяемо , на неправильные данные он реагирует исключением (или NAN), и уже дело программиста поставить ASSERT() на проверку аргумента перед отсылкой в Sqrt.
...
M>Это совершенно неправильное идеологически использование ASSERT, этим должны заниматься штатные средства обработки входных параметров (исключения, коды ошибок).

Дык ASSERT — это (на машинном уровне) и есть исключение и внутри Sqrt он уже поставлен за нас.

Так что Sqrt — хороший пример компонента обороняющегося от ошибок внешних компонентов с помощью ASSERT(x >= 0) на входные данные.

M>ASSERT был введен для совсем других целей, ASSERT это целая культура и идеология. Если вы проверяете входные параметры с помощью ASSERT , лучше заведите другой термин "VALIDATE_INPUT" и не путать одно с другим.

Если менять названия, тогда уж лучше на такие: ASSERT.PRECONDITION(), ASSERT.INVARIANT(), ASSERT.POSTCONDITION().

---

Обратите внимание на разницу между двумя типами ситуаций:
1) Данные впихиваются в компонент другим компонентом.
2) Компонент самостоятельно пытается откуда-то взять данные.

В первом случае компонент над которым производят действие имеет право жестоко обороняться (с помощью ассертов/исключений).
Во втором случае компоненту оборонятся не от кого, т.е. ассерты/исключения и т.п. тут не при чём.

СГ>Так что Sqrt — хороший пример компонента обороняющегося от ошибок внешних компонентов с помощью ASSERT(x >= 0) на входные данные.

Сомневаюсь, что ASSERT в Sqrt нужен.
Sqrt просто может вернуть NaN и пусть клиент сам решает, что делать — падать или продолжать работать.
ASSERT просто обрушит программу не позволяя сохранить данные.

Я специально подчеркнул что , все мною излагаемое касалось C/C++.

Только позвольте поинтересоваться КАК в языке в котором ASSERT является штатным средством обработки неправильных данных , ASSERT вообще может убираться в релизе ?

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

Здравствуйте, Сергей Губанов, Вы писали:

GZ>>1. Роль — программист который делает модуль. Для него ассерт как таковой информативен, поскольку несет в себе информацию о месте возникновения ошибки. Имея место, существует надежда что он может локализовать ошибку.
СГ>У него ассерты не срабатывают никогда, так как его модуль не содержит ошибок.
Нет. Как раз у него и срабатывают assert на этапе разработки. Собственно он и есть пользователь assert. В дальнейшем они не нужны.

GZ>>2. Роль — программист-клиент модуля. Для него ассерт по боку. Если он получит ассерт, то единственное что он поймет что где-то что-то у нас порой. Для него нужна более информативная ошибка о неверных параметрах, и каким образом он дошел до такой жизни.
СГ>Наоборот.
СГ>Для программиста второго модуля эти ассерты очень даже информативны, так как показывают, что он использовал первый модуль не так как положено. Он смотрит на полученное сообщение об ошибке (весь стек вызова со всеми полями объектов):
СГ>понимает, что это он — дурак и исправляет ошибку в своём модуле.
Какая разница в основных языках у assert и exception. Разница маленькая, exception посылает текст ошибки, и assert кроме того что содержит место в исходниках где проверялось условие, предоставляет возможность загрузить отладчик. В случае релиза — первое нужно, а вот отладчик — совсем не нужен.

GZ>>3. Роль — клиент.
СГ>А клиент, тут вообще не причем. Ему поставляется система без ошибок.
Ну вообще-то нет. Клиент есть машина по генерации непредвиденных ситуаций. Ну а на непредвиденные ситуации также нужно обрабатывать и отвечать вразумительными ответами.

С уважением, Gleb.

Здравствуйте, minorlogic, Вы писали:

M>Я специально подчеркнул что , все мною излагаемое касалось C/C++.

Ну вот и хорошо.
А эту ветку форума я затеял как обсуждение фрагмента из хелпа к Блэкбоксу, т.е. для языка Component Pascal.

M>Только позвольте поинтересоваться КАК в языке в котором ASSERT является штатным средством обработки неправильных данных , ASSERT вообще может убираться в релизе ?

Дык он и не убирается. В этом весь смысл. Система Блэкбокс — расширяемая. Ни когда нельзя сказать, что вот теперь она окончательно готова и далее расширять ее запрещено.

M>тот ASSERT про кторый я говорю , не нужен в релизе , поскольку он полезен только разработчику модуля.

Я утверждаю прямо противоположное ("выворачиваю наизнанку"). Ассерт на предусловия нужен вовсе не разработчику этого модуля, а другому разработчику другого модуля, который использует первый модуль. Вспомним Sqrt — ассерт в ней нужен не лично для неё самой, а для того чтобы сразу дать как можно сильнее по башке тому, кто попытается её неправильно использовать.

Здравствуйте, MShura, Вы писали:

СГ>>Так что Sqrt — хороший пример компонента обороняющегося от ошибок внешних компонентов с помощью ASSERT(x >= 0) на входные данные.

MS>Сомневаюсь, что ASSERT в Sqrt нужен.
MS>Sqrt просто может вернуть NaN и пусть клиент сам решает, что делать — падать или продолжать работать.

Ну, тоже вариант. Если в интерфейсе Sqrt прописать, что она может возвращать NaN, то пусть возвращает...

MS>ASSERT просто обрушит программу не позволяя сохранить данные.

Это смотря какую программу. На Си/С++ — легко. В Блэкбоксе на Component Pascal — ничего подобного, там просто снимется выполнение этой ошибочной команды. Данные никуда пропадать от этого не обязаны — смотря как напишешь. Но не зависимо от этого, в любом случае — сработавший ассерт — это ошибка в программе и её надо переписывать.

Здравствуйте, Сергей Губанов, Вы писали:

M>>Только позвольте поинтересоваться КАК в языке в котором ASSERT является штатным средством обработки неправильных данных , ASSERT вообще может убираться в релизе ?
СГ>Дык он и не убирается. В этом весь смысл.

Тогда о чём статья вообще? Убедить разработчиков BlackBox, что и не надо такую возможность добавлять? А они читают этот форум?