Здравствуйте, aik, Вы писали:
aik>Здесь ошибка. Вместо
aik>ASSERT(szFirstName != NULL);
aik>надо писать
aik>ASSERT(szFirstName != NULL);
aik>if (NULL == szFirstName)
aik> return -1;
Не надо так писать. Если у тебя есть нормальный способ обработать ошибку — обрабатывай ошибку. Ассерт здесь не нужен. Ассерт нужен для проверки выполнения договоренностей.
aik>Так и ассерт не нужен. Везде, всегда проверять коды возвратов. Но, в общем, я описал почему может быть запрет на ассерты,
Нет, пока не написал. Ты написал, что ассерты приводят к зависанию до нажатия кнопки. Это, извини, не имеет ничего общего с действительностью, данной мне в ощущениях.
aik>кто хотел — тот понял, кто не хочет понимать — будет упираться.
Ну почему же упираться? Мне правда интересно. Я вот всю жизнь думал, что ассерты есть абсолютное благо. Не знаю ни одной проблемы от использования ассертов. Знаю проблемы от неверного использования ассертов. А тут оказывается, что может быть какой-то вред. Надо срочно узнать, какой именно — иначе я спать спокойно не смогу.
aik>Дальше тему развивать не интересно.
Ну как же, мы ведь только начали!
Дальше мы, я думаю, придем еще к чему-нибудь про читаемость кода. Ну там, к вредности использовать code convention, к запрету на комментарии в исходниках... Что у нас там еще из области догм по поводу читаемости кода есть? Давайте разрушим эти замшелые скрижали.

aik wrote:

> Аварийная остановка — плохо. У тебя система видео-наблюдения работает
> или диск пишется — аварийная остановка фатальна.

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

> Вот сейчас с фирмварью вожусь — ну куда там ассертить? Это power
> management controller, он повиснет — дорогой, очень дорогой телекомный
> ящик встанет колом и целая деревня без телефонов сидеть будет,
> например. Там и аварийно остановиться нельзя даже.

А лучше будет, если вдруг вместо 220 вольт на железку пойдет 110?

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

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

aik>>Здесь ошибка. Вместо
aik>>ASSERT(szFirstName != NULL);
aik>>надо писать
aik>>ASSERT(szFirstName != NULL);
aik>>if (NULL == szFirstName)
aik>> return -1;
aik>>Так и ассерт не нужен. Везде, всегда проверять коды возвратов. Но, в общем, я описал почему может быть запрет на ассерты, кто хотел — тот понял, кто не хочет понимать — будет упираться. Дальше тему развивать не интересно.
LM>ТОгда уж лучше исключения. И корректно обрабатывать все такие ситуации...

О да... Темаааа... Нет уж, спасибо. Очень опасная штука, которую лично я бы советовал применять только с чужим кодом. Но это другая тема.

LM>Времени своего не жалко?

На что времени? Лишний if написать? У кого то это больше 15 секунд занимает? У меня в виндовых проектах так вообще есть макрос, который, если что не так, пишет в ATLTRACE сырец, строку, ассертит и возвращает E_POINTER на Ignore. В релизе и ассертить/писать не будет, но выполнение программы не изменится. Называется _ER. Его набор занимает вообще 5 секунд.

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

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

>> Аварийная остановка — плохо. У тебя система видео-наблюдения работает
>> или диск пишется — аварийная остановка фатальна.
C>А лучше будет, если из-за запорченой памяти система видеонаблюдения
C>сотрет все записаные данные? Может проще по assert'у намертво остановить
C>все (с максимальной руганью в лог), а потом перезапустить все по
C>тайм-ауту watchdog'а.

Как это "все"? Будет долго и упорно удалять файлы с харда? Не, ну все возможно, конечно, но реальнее гораздо незапись индекса в AVI файл (без этого файл — мертвый набор байтов) из-за ассерта, который грохнул процесс и не дал фильтру сбросить индекс.

>> Вот сейчас с фирмварью вожусь — ну куда там ассертить? Это power
>> management controller, он повиснет — дорогой, очень дорогой телекомный
>> ящик встанет колом и целая деревня без телефонов сидеть будет,
>> например. Там и аварийно остановиться нельзя даже.
C>А лучше будет, если вдруг вместо 220 вольт на железку пойдет 110?

36 Микруха, контроллирующая токи, не пропустит такое. Это — хардварный ассерт Но, благодаря неповисшей фирмвари, мы сможем понять что реально напряжение упало и переинитить определенные контроллеры.

Но вообще понятно, кто не писал систем 24*7, не поймут как жить без ассертов

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

E>>Имхо, самая большая проблема ASSERT-ов это то, что они выбрасываются из production кода. Абыдна бывает получать в production ошибку в функции RegisterUser (или даже в дебрях SaveToDb) из-за того, что где-то выше один из szFirstName, szLastName получился нулевым.
S>Нет. Если там стоял ассерт, то ты получил ошибку из-за того, что test coverage был неполным. А если он был неполным, то нефиг выкидывать ассерты из продакшна.

Это в пределе. К которому нужно стремиться.

E>>Благодоря ASSERT-ам мы теряем возможность быстро продиагностировать проблему.
S>А что, без ассерта ты имел какую-то возможность быстро продиагностировать проблему? Расскажи мне, что это за замечательная возможность. Я тоже хочу ей пользоваться.

Да все просто. Вместо ASSERT-а, который исчезает с NDEBUG делаешь простые проверки с abort-ом или порождением исключения. Эти проверки остаются в production системе.

int RegisterUser(char * szFirstName, char* szLastName)
{
    if( !szFirstName )
        abort_program( "RegisterUser: szFirstName == NULL" );
    if( !szLastName )
        abort_program( "RegisterUser: szLastName == NULL" );

    if(strlen(szLastName) == 0) // а вот тут уже пользовательский ввод
    {
        return -1; // возвращаем код ошибки, чтобы вызывающий код мог отразить это в интерфейсе
    }
    return SaveToDb(szFirstName, szLastName);
}

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

S>Здравствуйте, aik, Вы писали:
aik>>Здесь ошибка. Вместо
aik>>ASSERT(szFirstName != NULL);
aik>>надо писать
aik>>ASSERT(szFirstName != NULL);
aik>>if (NULL == szFirstName)
aik>> return -1;
S>Не надо так писать. Если у тебя есть нормальный способ обработать ошибку — обрабатывай ошибку. Ассерт здесь не нужен. Ассерт нужен для проверки выполнения договоренностей.

Все не отловишь, значит, все равно надо все проверять, значит, ассерты не так полезны.

aik>>Так и ассерт не нужен. Везде, всегда проверять коды возвратов. Но, в общем, я описал почему может быть запрет на ассерты,
S>Нет, пока не написал. Ты написал, что ассерты приводят к зависанию до нажатия кнопки. Это, извини, не имеет ничего общего с действительностью, данной мне в ощущениях.

Диалог _CrtDbgReport. Консольный еще лучше — просто пишет об ошибке и грохает приложение. Шикарно.

aik>>кто хотел — тот понял, кто не хочет понимать — будет упираться.
S>Ну почему же упираться? Мне правда интересно. Я вот всю жизнь думал, что ассерты есть абсолютное благо.

Лет 5 назад, и я так думал. Абсолютное благо — только в деструкторах, которые вызываются автоматом

S>Не знаю ни одной проблемы от использования ассертов. Знаю проблемы от неверного использования ассертов. А тут оказывается, что может быть какой-то вред. Надо срочно узнать, какой именно — иначе я спать спокойно не смогу.

Он останавливает выполнение и затем грохает процесс. Я это уже писал.

aik>>Дальше тему развивать не интересно.
S>Ну как же, мы ведь только начали!
S>Дальше мы, я думаю, придем еще к чему-нибудь про читаемость кода. Ну там, к вредности использовать code convention, к запрету на комментарии в исходниках... Что у нас там еще из области догм по поводу читаемости кода есть? Давайте разрушим эти замшелые скрижали.

Про читаемость — это с кем то другим У меня главный критерий кода — проходимость дебагером. Т. е. минимум многострочных дефайнов и "один оператор — одна строка".

Еще из наблюдений (это не против ассертов, а вообще ) — msvc2003 клинит на ассертах через раз. Хотя, наверное, на нее так DirectShow реагирует, или p2-400. Но — задолбала. Не в курсе как это подправить?

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

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

M>По второму кругу , кто тебе мешает определить асерт в релизе , чтобы он скидывал логи ?

Тогда это будет не assert.
Смысл assert-а в том, что он исчезает из кода при компиляции с NDEBUG. Если же в production он остается, значит это не assert, а обычная проверка.

Не знаю как у вас с асертами а у меня они ничего не грохают . ЭТО ЖЕ МОИ АСЕРТЫ , я им хозян , что скажу то и сделают .

Если мне надо то завалят систему , если нет то в лог чего то запишут.

Как пример , в BCB5 родной стандартный "assert" из рантайма вешал всю среду выполнения . Конечно первое что я сделал , это переписал реализацию макроса "assert".

В общем если он у вас ведет себя не так как вы ожидаете , это ваша проблема

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

aik>Но вообще понятно, кто не писал систем 24*7, не поймут как жить без ассертов

Я последние 6 лет пишу "24*7". Могу отвественно заявить, что без ассертов в случае сложной системы ты повесишься. Особенно для достаточно сложной асинхронной системы. Синклер тебе написал все правильно. Рекомендую перечитать и подумать.

Примеры использования ассертов, которые ты приводил — очень плохи. У нас в компании подобный код не пройдет инспекцию и будет запрещен к чекину. Основная философия написания отказоустойчивых систем — это let it crash с подробной информацией как можно раньше, с последующим перехватом и обработкой ошибки. Оттягивание обработки ошибочной ситуации и игнорирование (фатальной) ошибки, как у тебя, не дает никакой пользы, кроме следующего вреда:
1) Очень сильно ухудшается читабельность кода. В разы. Что затрудняет сопровождение.
2) При фатальной ошибке прога все равно упадет, но в другом месте, и с такими дикими симптомами, что причину ошибки ты вообще не найдешь. Я говорю, разумеется, о достаточно сложных системах, от полмиллиона строк и выше. А не о микроконтроллерах.

Дополню Синклера — он не договорил до конца. Ассерты применяются для практической реализации техники формальных спецификаций. Упрощенно — она состоит в том, что для функций определяется пара "предусловие" и "постусловие". Пример для сортировки: предусловие — true. постусловие — x[i] <= [i+1] для всех 0 < i < N-1. Вычисление постусловия занимает O(N) времени, и, разумеется, должно быть выкинуто из релиза. В дебаге ошибка через этот assert не пройдет.

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

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

M>>По второму кругу , кто тебе мешает определить асерт в релизе , чтобы он скидывал логи ?

E>Тогда это будет не assert.
E>Смысл assert-а в том, что он исчезает из кода при компиляции с NDEBUG. Если же в production он остается, значит это не assert, а обычная проверка.

Ну тогда определяйтесь с терминологией , без развода флейма.

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

M>Не знаю как у вас с асертами а у меня они ничего не грохают . ЭТО ЖЕ МОИ АСЕРТЫ , я им хозян , что скажу то и сделают .
M>Если мне надо то завалят систему , если нет то в лог чего то запишут.
M>Как пример , в BCB5 родной стандартный "assert" из рантайма вешал всю среду выполнения . Конечно первое что я сделал , это переписал реализацию макроса "assert".
M>В общем если он у вас ведет себя не так как вы ожидаете , это ваша проблема

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

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

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

Жду твоего определения.

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

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

M>Жду твоего определения.

http://www.opengroup.org/onlinepubs/007908799/xsh/assert.html

The assert() macro inserts diagnostics into programs. When it is executed, if expression is false (that is, compares equal to 0), assert() writes information about the particular call that failed (including the text of the argument, the name of the source file and the source file line number — the latter are respectively the values of the preprocessing macros __FILE__ and __LINE__) on stderr and calls abort().

Forcing a definition of the name NDEBUG, either from the compiler command line or with the preprocessor control statement #define NDEBUG ahead of the #include <assert.h> statement, will stop assertions from being compiled into the program.

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

aik>>Но вообще понятно, кто не писал систем 24*7, не поймут как жить без ассертов
G>Я последние 6 лет пишу "24*7". Могу отвественно заявить, что без ассертов в случае сложной системы ты повесишься. Особенно для достаточно сложной асинхронной системы. Синклер тебе написал все правильно. Рекомендую перечитать и подумать.

Перечитал, и утверждаю что — не повесился. Вероятно, в твоем проекте повеситься без ассертов — можно.

G>Примеры использования ассертов, которые ты приводил — очень плохи. У нас в компании подобный код не пройдет инспекцию и будет запрещен к чекину. Основная философия написания отказоустойчивых систем — это let it crash с подробной информацией как можно раньше, с последующим перехватом и обработкой ошибки. Оттягивание обработки ошибочной ситуации и игнорирование (фатальной) ошибки, как у тебя, не дает никакой пользы, кроме следующего вреда:

Игнорирования нет. Есть возврата кода с ошибкой, который будет обработан в вызывающем коде, либо и он отдаст ошибку выше. Очень грубо говоря, это обратная раскрутка стека как при поиске обработчика исключения.
"let it crash" — вообще подозрительный подход. Мне больше нравится "если уж crash, то с максимальной информацией".

G>1) Очень сильно ухудшается читабельность кода. В разы. Что затрудняет сопровождение.

Неа. Что ассерт, что if(blabla) { ATLTRACE(blabla); return E_FAIL; } — один хрен.

G>2) При фатальной ошибке прога все равно упадет, но в другом месте, и с такими дикими симптомами, что причину ошибки ты вообще не найдешь. Я говорю, разумеется, о достаточно сложных системах, от полмиллиона строк и выше. А не о микроконтроллерах.

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


G>Дополню Синклера — он не договорил до конца. Ассерты применяются для практической реализации техники формальных спецификаций. Упрощенно — она состоит в том, что для функций определяется пара "предусловие" и "постусловие". Пример для сортировки: предусловие — true. постусловие — x[i] <= [i+1] для всех 0 < i < N-1. Вычисление постусловия занимает O(N) времени, и, разумеется, должно быть выкинуто из релиза. В дебаге ошибка через этот assert не пройдет.

В релизе — пройдет, релиз — это основной поставщик сложных ошибок.

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

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

aik>Еще из наблюдений (это не против ассертов, а вообще ) — msvc2003 клинит на ассертах через раз. Хотя, наверное, на нее так DirectShow реагирует, или p2-400. Но — задолбала. Не в курсе как это подправить?

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

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

aik>>Еще из наблюдений (это не против ассертов, а вообще ) — msvc2003 клинит на ассертах через раз. Хотя, наверное, на нее так DirectShow реагирует, или p2-400. Но — задолбала. Не в курсе как это подправить?

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

не, совсем не то. У меня студия долго отрабатывает int3. Видимо, пытается за suspend'ить потоки процесса и не может, потому что некоторые в ядре что ли... Не понимаю я ее. С msvc6 таких напрягов не было.

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

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

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

M>>Жду твоего определения.

E>http://www.opengroup.org/onlinepubs/007908799/xsh/assert.html
E>

E>The assert() macro inserts diagnostics into programs. When it is executed, if expression is false (that is, compares equal to 0), assert() writes information about the particular call that failed (including the text of the argument, the name of the source file and the source file line number — the latter are respectively the values of the preprocessing macros __FILE__ and __LINE__) on stderr and calls abort().

E>Forcing a definition of the name NDEBUG, either from the compiler command line or with the preprocessor control statement #define NDEBUG ahead of the #include <assert.h> statement, will stop assertions from being compiled into the program.

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

интерессно также почитать что на эту тему пишут в стандарте

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

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

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

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

aik>>>ASSERT(szFirstName != NULL);
aik>>>if (NULL == szFirstName)
aik>>> return -1;
S>>Не надо так писать. Если у тебя есть нормальный способ обработать ошибку — обрабатывай ошибку. Ассерт здесь не нужен. Ассерт нужен для проверки выполнения договоренностей.

aik>Все не отловишь, значит, все равно надо все проверять, значит, ассерты не так полезны.

ok, еще один рывок, еще одна попытка Срабатывание assert-а означает безусловную необходимость изменения кода (текста программы), вызвавшего его срабатывание. Дружественым if (NULL == szFirstName) return -1; ты ни себя, ни кого другого на изменение кода не нагнешь.