ARV писал(а):по-моему, единственный способ хоть как-то контролировать переполнение результата в математических расчетах на Си.
Вообще, по-моему, это единственный способ написать более-менее читаемую программу на C. Иначе мы обречены либо после каждой мало-мальски содержательной операции, которая в принципе может завершиться с ошибкой, проверять коды возврата функции и городить код обработки ошибки (а сама обработка тоже может привести к ошибке, и получается сказка про белого бычка), либо анализировать глобальную переменную errno, что тоже не блещет красотой.
Единственный нормальный вариант - использовать
гарантированно защищенный блок Try, в котором содержится вся логика при нормальном исполнении, и единую область обработки ошибок, не раскиданную по всему тексту.
ARV писал(а):как же обрабатывать исключения? ведь чаще всего они служат для информирования пользователя, реже - для автоматического сбора информации, отсылаемой затем разработчику, и уж совсем редко для корректировки поведения программы.
Это нас так приучили нерадивые программисты, увы... Сообщение "Программа выполнила недопустимую операцию и будет закрыта", после которого следует длинный дамп содержимого регистров и стека, обычному пользователю не дает никакой полезной информации. Я хочу знать конкретную причину - закончилось место на диске, нет нужной DLL, пропало соединение с сетью и т.д., а вовсе не адрес команды, где эта беда случилась.
Автоматическая кляуза разработчику - это уже более приемлемый вариант, есть шанс, что информация попадет по адресу.
Корректировка поведения программы с целью минимизации последствий сбоя - наиболее разумная обработка исключительной ситуации. Но разумное требует применения разума, то есть затраты умственного труда гораздо выше, чем в первых двух случаях. Зато и результат получается наилучший.
ARV писал(а):все "исправление" поведения программы так или иначе сведется к игнорированию неправильных данных/результатов...
Если нет более разумных вариантов, то хотя бы прекратить дальнейшее выполнение части программы с бессмысленными данными может быть лучшим выходом. Особенно если программа циклическая и пропуск одного цикла не будет катастрофическим.
ARV писал(а):ну так Си и без этого игнорирует практически все на свете проблемы.
И тем самым попросту перекладывает эти проблемы на наши плечи. Собственно, потому я и задал свой вопрос - как в этих не самых благоприятных условиях создаются более-менее надежные устройства? Обрабатывать коды ошибок "в лоб" слишком трудоемко и чревато новыми ошибками, тестировать вручную - вообще неподъемно (если не считать тестированием единичный прогон программы под отладчиком, как часто бывает). Нужна действенная помощь инструментов, а кое в чем и другие подходы к написанию программ. Кое-что удалось раскопать самому, кое-чему надеюсь научиться у других, - делитесь, кто не жадный.
P.S. Если понравилась статья по
CException, то поглядите еще вот эту:
http://club.shelek.ru/viewart.php?id=338 . Ее автор, к сожалению, не я; но когда я ее прочитал, понял, что просто
обязан ее перевести, не должны такие вещи оставаться незамеченными. Конечно, те, кто привык пользоваться RTOS, имеют возможность организовать кооперативную мультизадачность и без этого; но на "голом" контроллере вполне может пригодиться.
Любой дурак может писать код. Настоящий профессионал - это тот, кто способен постоянно создавать продукт высокого качества, укладываясь при этом в бюджет.
J. Ganssle
в тестировании: многие стандарты в области программного обеспечения черпают свои определения от туда.
Сам был уже почти на грани того, чтобы написать самостоятельно что-то аналогичное, но лень побеждала... Еще с тех пор, как познакомился с исключениями в Delphi - очень ценю это средство реакции на ошибки. в частности, по-моему, единственный способ хоть как-то контролировать переполнение результата в математических расчетах на Си. 
