На здоровье :

return_code func( handle h)
{
if( h == 0 )
{
assert(0 && "invalid handle passed in function func");
return INVALID_HANDLE_RESULT_CODE;
}
.....
}

С Sqrt вааще все просто :

double Sqrt( double v)
{
assert( (v >= 0) && "passed negative value into sqrt func" );
if( v < 0 )
return NAN;
return sqrt(v);
}

AVC>(Разумеется, есть куча ситуаций, когда необходимо проверять возврат функции: открытие файла, запрос памяти в куче с помощью malloc etc. Но есть ситуации, где клиенту надо проверить корректность аргументов вызываемой функции. О них и идет речь.)

Как вы относитесь к утвержению, что правильная программа, которая работает месяцами, должна проверять результаты перед каждой операцией. Даже перед обычными арифметическими операциями.
Т.е. процессор предоставляет вам, например, операцию сложения с её ограничениями, если вы вызываете эту операцию, то вы должны проверить аргументы и результат, либо только аргументы, если уверены, что при правильных аргументах будет правильный результат. Очевидно, что процессор не вызывает никаких ASSERT, а только взводит флаги в случае ошибки. Учитывать или не учитывать ошибку это дело клиента, а не самого процессора.

0rc>>А если ASSERT включен на Марсе, что тогда, легче будет?

VD>Ещё бы! Сейчас не те времена! Залезаем на марсоход через терминалку и жмем "Ignore". А если писать код на интерпретаторе или на языке поддерживющем модификаци кода без перекомпиляции, то ваще жмем "Retry" и правим код!

А вот зря смеетесь
Lisp на Марсе (еще есть история у Franz):

The Remote Agent software, running on a custom port of Harlequin Common Lisp, flew aboard Deep Space 1 (DS1), the first mission of NASA's New Millennium program. Remote Agent controlled DS1 for two days in May of 1999. During that time we were able to debug and fix a race condition that had not shown up during ground testing. (Debugging a program running on a $100M piece of hardware that is 100 million miles away is an interesting experience. Having a read-eval-print loop running on the spacecraft proved invaluable in finding and fixing the problem.

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

AVC>>(Разумеется, есть куча ситуаций, когда необходимо проверять возврат функции: открытие файла, запрос памяти в куче с помощью malloc etc. Но есть ситуации, где клиенту надо проверить корректность аргументов вызываемой функции. О них и идет речь.)

MS>Как вы относитесь к утвержению, что правильная программа, которая работает месяцами, должна проверять результаты перед каждой операцией. Даже перед обычными арифметическими операциями.
MS>Т.е. процессор предоставляет вам, например, операцию сложения с её ограничениями, если вы вызываете эту операцию, то вы должны проверить аргументы и результат, либо только аргументы, если уверены, что при правильных аргументах будет правильный результат. Очевидно, что процессор не вызывает никаких ASSERT, а только взводит флаги в случае ошибки. Учитывать или не учитывать ошибку это дело клиента, а не самого процессора.

Почему "даже перед обычными арифметическими операциями"? Чем арифметические операции хуже других?
Далеко не всегда процессор ограничивается выставлением флагов. Самый простой пример: инструкции DIV и IDIV вызывают прерывание при попытке деления на ноль. Чем не аналог ASSERT?
Рассмотрим ситуацию, когда при выполнении арифметической операции прерывание не вызывается.
Как правило, при сложении или вычитании переполнение не ведет к прерыванию.
Возможны две ситуации.
(1) Взводится флаг переполнения (если таковой имеется).
В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
(2) Процессор простой, даже флага переполнения нет.
В таком случае компилятор может сам сгенерировать проверку переполнения (опять же зависит от опций).
Делается это примерно так (отрывок из виртовского "Compiler construction")

Whenever arithmetic expressions are evaluated, the inherent danger of overflow exists. The evaluating
statements should therefore be suitably guarded. In the case of addition guards can be formulated as
follows:

IF x.a >= 0 THEN
  IF y.a <= MAX(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("overflow") END
ELSE
  IF y.a >= MIN(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("underflow") END
END

The essence of delayed code generation is that code is not emitted before it is clear that no better solution
exists. For example, an operand is not loaded into a register before this is known to be unavoidable.

Как видите, это полный аналог ASSERT, создаваемый самим компилятором.
Но что это мы все об арифметике, да об арифметике?
Рассмотрим операции связанные с доступом к памяти:
— разыменование указателя;
— взятие элемента массива по индексу.
Надеюсь, здесь у Вас не будет возражений, что разыменование "невалидного" указателя и выход индекса за границы массива — недопустимые операции? (Хотя у некоторых Си-программистов даже это может вызвать возражения... )
Значит, требуется предварительная проверка указателя и индекса на корректность. И то, и другое, к примеру, в Обероне требуют всего одной операции сравнения.
Опять же — предварительная проверка и исключение (ловушка) в случае невыполнения требований. Полный аналог ASSERT.
Собственно, явный ASSERT требуется только тогда, когда компилятор не может вставить его сам (неявно).
Позволю себе привести две цитаты из Хоара (одну из них тут даже приписали... Страуструпу ).

It is absurd to make elaborate security checks on debugging runs, when no trust
is put in the results, and then remove them in production runs, when an erroneous
result could be expensive or disastrous. What would we think of a sailing
enthusiast who wears his life-jacket when training on dry land but takes it off as
soon as he goes to sea?

In our Algol compiler every occurrence of every subscript of every array element
was on every occasion checked at run time against the declared bounds. Many
years later we asked our customers whether they wished us to provide an option
to switch off these checks in the interest of efficiency in production runs.
Unanimously they urged us not to — they already knew how frequently index
errors occur on production runs where failure could be disastrous. I note with
fear and horror that even today, language designers and users have not learned
this lesson. In any respectable branch of engineering, failure to observe such
elementary precautions would have long been against the law.

Последнее предложение выделил для внушительности.

AVC>Почему "даже перед обычными арифметическими операциями"? Чем арифметические операции хуже других?
AVC>Далеко не всегда процессор ограничивается выставлением флагов. Самый простой пример: инструкции DIV и IDIV вызывают прерывание при попытке деления на ноль. Чем не аналог ASSERT?

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

Если вы помните начало ветки про Sqrt, то противниками ASSERT как раз предлагалось два варианта
— Кинуть исключение
— Вернуть NaN

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


AVC>Рассмотрим ситуацию, когда при выполнении арифметической операции прерывание не вызывается.
AVC>Как правило, при сложении или вычитании переполнение не ведет к прерыванию.
AVC>Возможны две ситуации.
AVC>(1) Взводится флаг переполнения (если таковой имеется).
AVC>В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
Чаще всего программисту нужны оба варианта.

AVC>(2) Процессор простой, даже флага переполнения нет.
AVC>В таком случае компилятор может сам сгенерировать проверку переполнения (опять же зависит от опций).
AVC>Делается это примерно так (отрывок из виртовского "Compiler construction")
AVC>

AVC>Whenever arithmetic expressions are evaluated, the inherent danger of overflow exists. The evaluating
AVC>statements should therefore be suitably guarded. In the case of addition guards can be formulated as
AVC>follows:
AVC>

AVC>IF x.a >= 0 THEN
AVC>  IF y.a <= MAX(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("overflow") END
AVC>ELSE
AVC>  IF y.a >= MIN(INTEGER) - x.a THEN x.a := x.a + y.a ELSE Mark("underflow") END
AVC>END
AVC>

AVC>The essence of delayed code generation is that code is not emitted before it is clear that no better solution
AVC>exists. For example, an operand is not loaded into a register before this is known to be unavoidable.

AVC>Как видите, это полный аналог ASSERT, создаваемый самим компилятором.

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



AVC>Но что это мы все об арифметике, да об арифметике?
AVC>Рассмотрим операции связанные с доступом к памяти:
AVC>- разыменование указателя;
AVC>- взятие элемента массива по индексу.
AVC>Надеюсь, здесь у Вас не будет возражений, что разыменование "невалидного" указателя и выход индекса за границы массива — недопустимые операции? (Хотя у некоторых Си-программистов даже это может вызвать возражения... )
AVC>Значит, требуется предварительная проверка указателя и индекса на корректность. И то, и другое, к примеру, в Обероне требуют всего одной операции сравнения.
AVC>Опять же — предварительная проверка и исключение (ловушка) в случае невыполнения требований. Полный аналог ASSERT.

Кинуть исключение лучше, что собственно разные OS и делают по разному, но с одинаковым эффектом.
Проверка индексов массива в случае когда они ВСЕГДА верны не имеет смысла.
Точно также как и проверка указателя после операции new, которая в случае нехватки памяти кидает исключение.
Если в этих случаях нет возможности исключить эти проверки, то грош цена таким компиляторам.

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


_FR>Я, например, не линюсь писать как-то так:

Это слово произошло от Linux?

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

MS>Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
MS>ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

Вы другие сообщения из этой ветки читать когда-нибудь будете? Сто раз тут уже было сказано! Но всё-равно обязательно найдётся ещё один, не успевший это прочитать!

Повторяю в сто первый раз:
1) ЭКВИВАЛЕНТНО!
2) НЕ ОСТАНОВИТ!

В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет поймано в системной ловушке (system-trap).
Не программа будет остановлена, а будет остановлена команда в которой произошла авария.
Сам Блэкбокс будет работать дальше как ни в чём не бывало.

Сергей Губанов wrote:

> В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет
> поймано в системной ловушке (system-trap).
> Не программа будет остановлена, а будет остановлена команда в которой
> произошла авария.

Ну да. После чего умрет весь поток (пардон, "активный объект").

> Сам Блэкбокс будет работать дальше как ни в чём не бывало.

Угу. "Улыбнется и пойдет дальше", как в анекдоте.

--
С уважением,
Alex Besogonov (alexy@izh.com)

СГ>Вы другие сообщения из этой ветки читать когда-нибудь будете? Сто раз тут уже было сказано! Но всё-равно обязательно найдётся ещё один, не успевший это прочитать!

Читать ветки Вашего авторства не хватит никакого времени.
Наверное программирование на Oberon освобождает очень много времени?
Я к сожалению пользуюсь более трудоемкими инструментами и времени у меня немного.

СГ>В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет поймано в системной ловушке (system-trap).
Объясните зачем тогда нужен ASSERT, если есть механизм исключений?


СГ>Не программа будет остановлена, а будет остановлена команда в которой произошла авария.
А что будет дальше? Программа будет ждать нажатия клавиши (кстати хорошее решение для серверов!) ?
В какое место будет передано управление после нажатия клавиши?
А если клиент предусмотрел обработку исключений при вызове этой функции, то system-trap все равно сработает?

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

VD>>Ещё бы! Сейчас не те времена! Залезаем на марсоход через терминалку и жмем "Ignore". А если писать код на интерпретаторе или на языке поддерживющем модификаци кода без перекомпиляции, то ваще жмем "Retry" и правим код!

M>А вот зря смеетесь

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

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

AVC>>Почему "даже перед обычными арифметическими операциями"? Чем арифметические операции хуже других?
AVC>>Далеко не всегда процессор ограничивается выставлением флагов. Самый простой пример: инструкции DIV и IDIV вызывают прерывание при попытке деления на ноль. Чем не аналог ASSERT?

MS>Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
MS>ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

Насколько я понимаю, это и есть Ваше настоящее возражение против ASSERT.
(В отличие от, ИМХО, "местечковой" ссылки на то, что кто-то и где-то использует ASSERT по-другому.)
Попытаемся разобраться вместе. Допускаю, что моя точка зрения может быть спорной и даже неверной..
Я же не вижу, как именно здесь клиент мог бы "исправиться".
(Я не стану еще раз повторять, что программа — BlackBox — не "упадет".
Ясно, что Вы под программой понимаете данный поток, в котором произошла ошибка.)
Посудите сами. Функция Sqrt имеет предусловие (x >= 0.0). Оно указано в документации к модулю Math.
Несмотря на это, программист не проверил значение x перед вызовом Sqrt, что гарантировало ему корректное вычисление квадратного корня.
Кроме того, он, похоже, не тестировал свою программу. (Иначе он с большой вероятностью столкнулся бы с данной ошибкой и все-таки вставил бы необходимую проверку.)
И как, по Вашему, он мог бы теперь "исправиться"?

Мне кажется, что здесь мы вышли за пределы обсуждения использования ASSERT в BlackBox.
Вопрос, скорее, о разумном использовании исключений вообще.
Интересно, была ли уже на RSDN такая ветка, не привязанная к специфике конкретного языка программирования или конкретной системы программирования?

MS>Если вы помните начало ветки про Sqrt, то противниками ASSERT как раз предлагалось два варианта
MS>- Кинуть исключение
MS>- Вернуть NaN

В принципе, и тот, и другой вариант заслуживает внимания.
В данном случае (Sqrt) я предпочитаю первый.
В рамках BlackBox ASSERT есть разновидность исключения.

Мне жаль, что за разногласиями по поводу правомерности использования ASSERT потерялась главная, ИМХО, деталь в утверждении Сергея Губанова. А именно — речь шла о расширяемых (extensible) системах.

AVC>>Рассмотрим ситуацию, когда при выполнении арифметической операции прерывание не вызывается.
AVC>>Как правило, при сложении или вычитании переполнение не ведет к прерыванию.
AVC>>Возможны две ситуации.
AVC>>(1) Взводится флаг переполнения (если таковой имеется).
AVC>>В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
MS>Чаще всего программисту нужны оба варианта.

Т.е. нужна и знаковая, и беззнаковая арифметика.
Не уверен, что они равноценны. Знаковая, ИМХО, "важнее".

MS>Проверка индексов массива в случае когда они ВСЕГДА верны не имеет смысла.

Мысль понятна. Например, в следующем цикле

FOR i := 0 TO LEN(a)-1 DO a[i] := 0 END; (* LEN(a) в Обероне = длина массива a *)

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

MS>Точно также как и проверка указателя после операции new, которая в случае нехватки памяти кидает исключение.

Тоже верно.
Но представьте следующую ситуацию:

p->foo();

если мы не уверены, был ли вообще инициализирован указатель p.

MS>Если в этих случаях нет возможности исключить эти проверки, то грош цена таким компиляторам.

Это крайнее суждение. (На всякий случай успокою Вас — возможность отключить проверки есть. Хотя я не уверен, что это правильно для операций с памятью в случае когда компилятор (не программист!) не может гарантироовать корректность индекса.)
У меня обратное (и тоже крайнее ) суждение: грош цена таким компиляторам, которые не могут вставить такие проверки в код (как минимум — для отладки).

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

AVC>>>В зависимости от заданных опций, компилятор может вставить проверку флага и сгененрировать соответствующее исключение. Какие опции выберет программист — зависит от его потребностей. Иногда арифметика по модулю 2 в степени n — то, что нужно. А иногда — нет.
MS>>Чаще всего программисту нужны оба варианта.

AVC>Т.е. нужна и знаковая, и беззнаковая арифметика.

Здесь меня, конечно, "переклинило".
Конечно, это не одно и то же.
Причины: усталость и всплывшая вдруг ассоциация с недавним кодом, где счетчик имел право переполняться.

M>>А вот зря смеетесь

VD>Дык, и в этой шутке есть доля шутки. Ты прикинь каким самообладанием нужно обладать, чтобы наботать по терминалке с компьютером находящемся на растоянии 8 световых минут.

Так мало, что 8 световых минут, так еще и на оборудовании стоимостью в н мегабаксов

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

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

MS>>Неужели вы не видете (?), что кидание исключения при неправильных аргументах это совершенно не эквивалентно ASSERT!
MS>>ASSERT остановит программу, а исключение даст шанс клиенту исправиться.

СГ>Вы другие сообщения из этой ветки читать когда-нибудь будете? Сто раз тут уже было сказано! Но всё-равно обязательно найдётся ещё один, не успевший это прочитать!

Вы же не отвечаете на другие посты , вот и приходиться повторять.

СГ>Повторяю в сто первый раз:
СГ>1) ЭКВИВАЛЕНТНО!
Если эквивалентно то ПОЧЕМУ кому либо в голову может прити в этой системе BlackBox отключать ASSERT в релизе ? Ну объясните , ну почему кому то не придет в голову в релизе отключить исключения ? или отулючить обработку ошибок как таковую в релизе ?

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

C>Ну да. После чего умрет весь поток (пардон, "активный объект").

В Блэкбоксе нет потоков и активных объектов.

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

СГ>>В Блэкбоксе ASSERT — это и есть кидание исключения, которое будет поймано в системной ловушке (system-trap).
MS>Объясните зачем тогда нужен ASSERT, если есть механизм исключений?

Механизма исключений в самом языке Component Pascal нет.

СГ>>Не программа будет остановлена, а будет остановлена команда в которой произошла авария.
MS>А что будет дальше? Программа будет ждать нажатия клавиши (кстати хорошее решение для серверов!) ?
MS>В какое место будет передано управление после нажатия клавиши?

Есть главный цикл, в котором крутится сам Блэкбокс. В него и вернётся.

MS>А если клиент предусмотрел обработку исключений при вызове этой функции, то system-trap все равно сработает?

Механизма исключений в самом языке Component Pascal нет, но в принципе, можно сделать так, что сработавший system-trap вызовет обработчик предусмотренный пользователем.

Сергей Губанов wrote:
> C>Ну да. После чего умрет весь поток (пардон, "активный объект").
> В Блэкбоксе нет потоков и активных объектов.
Ээээ? А что там есть?

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Сергей Губанов wrote:
>> C>Ну да. После чего умрет весь поток (пардон, "активный объект").
>> В Блэкбоксе нет потоков и активных объектов.
C>Ээээ? А что там есть?

Чёрный ящик же — исследователь ничего о содержимом не знает

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

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

C>>Сергей Губанов wrote:
>>> C>Ну да. После чего умрет весь поток (пардон, "активный объект").
>>> В Блэкбоксе нет потоков и активных объектов.
C>>Ээээ? А что там есть?

К>Чёрный ящик же — исследователь ничего о содержимом не знает

Думаю, там нет ничего — чистый вакуум. Потому что сферические кони в другой среде не живут