Где бы прочитать про философию работы с исключениями. Прочитал в MSDN -- но все равно чувствую недостаток информации, да и сами MS, как мне кажется, работать с исключениями не умеют: программы их падают и почему-то постоянно закрываются, даже когда этого можно было бы и не делать.
Здравствуйте, 0K, Вы писали:
0K>Где бы прочитать про философию работы с исключениями. Прочитал в MSDN -- но все равно чувствую недостаток информации, да и сами MS, как мне кажется, работать с исключениями не умеют: программы их падают и почему-то постоянно закрываются, даже когда этого можно было бы и не делать.
Здравствуйте, 0K, Вы писали:
0K>программы их падают и почему-то постоянно закрываются, даже когда этого можно было бы и не делать.
Ну, дык это известный компромисс между корректностью("падать сразу") и устойчивостью("держаться до последнего").
Какой из подходов выбрать — зависит от приложения.
Вот что по этому поводу написано в книге Макконнелла:
( Макконнелл С. "Совершенный код. Мастер-класс" / Пер. с англ. — М.: Издетальство "Русская Редакция", 2007.)
с.189
Иногда наилучшей реакцией на неправильные данные будет продолжение выполнения и возврат заведомо безопасного значения. Численные расчеты могут возвращать 0. Операция со строкой может вернуть пустую строку, а операция с указателем — пустой указатель. Метод рисования в видеоигре, получивший неправильное исходное значение цвета, может по умолчанию использовать цвет фона или изображения. Однако в методе рисования рентгеновского снимка ракового больного вряд ли стоит применять «нейтральное значение». В таких случаях лучше прекратить выполнение программы, чем показать пациенту неправильные результаты.
с.191
Некоторые системы прекращают работу при возникновении любой ошибки. Этот подход оправдан в приложениях, критичных к безопасности. Например, какая реакция на ошибку будет наилучшей, если ПО, контролирующее радиационное оборудование для лечения рака, получит некорректное значение радиационной дозы? Надо ли использовать то же значение, что и в предыдущий раз? А может, ближайшее допустимое или нейтральное значение? В этом случае остановка работы — наилучший вариант. Мы охотнее предпочтем перезагрузить машину, чем рискнуть применить неправильную дозу.
с.192
Устойчивость против корректности
Как нам показали примеры с видеоигрой и рентгеновской установкой, выбор подходящего метода обработки ошибки зависит от приложения, в котором эта ошибка происходит. Кроме того, обработка ошибок в общем случае может стремиться либо к большей корректности, либо к большей устойчивости кода. Разработчики привыкли применять эти термины неформально, но, строго говоря, эти термины находятся на разных концах шкалы. Корректность предполагает, что нельзя возвращать неточный результат; лучше не вернуть ничего, чем неточное значение. Устойчивость требует всегда пытаться сделать что-то, что позволит программе продолжить работу, даже если это приведет к частично неверным результатам.
Приложения, требовательные к безопасности, часто предпочитают корректность устойчивости. Лучше не вернуть никакого результата, чем неправильный результат. Радиационная машина — хороший пример применения такого принципа.
В потребительских приложениях устойчивость, напротив, предпочтительнее корректности. Какой-то результат всегда лучше, чем прекращение работы. Текстовый редактор, которым я пользуюсь, временами показывает последнюю на экране строку лишь частично. Хочу ли я, чтобы при обнаружении этой ситуации редактор завершал выполнение? Нет: когда я в следующий раз нажму Page Up или Page Down, экран обновится, и изображение исправится.
Здравствуйте, 0K, Вы писали:
0K>Где бы прочитать про философию работы с исключениями. Прочитал в MSDN -- но все равно чувствую недостаток информации, да и сами MS, как мне кажется, работать с исключениями не умеют: программы их падают и почему-то постоянно закрываются, даже когда этого можно было бы и не делать.
Герба Саттера читайте.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, SergeyT., Вы писали:
0K>>Где бы прочитать про философию работы с исключениями. Прочитал в MSDN -- но все равно чувствую недостаток информации, да и сами MS, как мне кажется, работать с исключениями не умеют: программы их падают и почему-то постоянно закрываются, даже когда этого можно было бы и не делать.
ST>Framework design guidelines by Cwalina, Abrams.
Здравствуйте, _FRED_, Вы писали:
_FR>Герба Саттера читайте.
У Герба отличные книги и статьи, но в них, в основном рассказывается о том, как не отстрелить себе ногу при наличии исключений именно в С++ (получить согласнованное состояние объектов, не допустить утечек памяти или ресурсов и т.д.), но для других языков это применимо в меньшей степени. Хотя его идеи о гарантии исключений очень интересны, но они так и не получили распространения в том же C#.
Кстати, у Герба есть классная статья, сравнивающая особенности исключений в конструкторе в C++, C# и Java (интересно читать, если читатель знаком хотя бы с двумя из трех этих языков): Constructor Exceptions in C++, C#, and Java
Здравствуйте, SergeyT., Вы писали:
_FR>>Герба Саттера читайте.
ST>У Герба отличные книги и статьи, но в них, в основном рассказывается о том, как не отстрелить себе ногу при наличии исключений именно в С++
Я имел в виду, в первую очередь, главы о разделении контрактов исключений между модулями.
ST>(получить согласнованное состояние объектов, не допустить утечек памяти или ресурсов и т.д.), но для других языков это применимо в меньшей степени. Хотя его идеи о гарантии исключений очень интересны, но они так и не получили распространения в том же C#.
А в том же дотнете так же необходимо понимать, что при throw надо или говорить, что объект не пригоден для дальнейшего использования или восстанавливать инварианты. Очень многие, к сожелению, об этом даже не слышали, не то что не думают. Согласованное состояние (за все языки не возьмусь) в дотнете вообще и шарпе в частности не менее важно, чем в С++. Просто народ себе голову этим не забивает Но проблемы те же самые.
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, andy1618, Вы писали: A> Устойчивость против корректности A> Как нам показали примеры с видеоигрой и рентгеновской установкой, выбор подходящего метода обработки ошибки зависит от приложения, в котором эта ошибка происходит. Кроме того, обработка ошибок в общем случае может стремиться либо к большей корректности, либо к большей устойчивости кода. Разработчики привыкли применять эти термины неформально, но, строго говоря, эти термины находятся на разных концах шкалы. Корректность предполагает, что нельзя возвращать неточный результат; лучше не вернуть ничего, чем неточное значение. Устойчивость требует всегда пытаться сделать что-то, что позволит программе продолжить работу, даже если это приведет к частично неверным результатам.
моя философия — в дебаге корректность, в релизе устойчивость.
Здравствуйте, _FRED_, Вы писали: _FR>Герба Саттера читайте.
кстати, это единственная книжка касательно программирования, которая оставила у меня отвратительное впечатление
Здравствуйте, __kot2, Вы писали:
__>моя философия — в дебаге корректность, в релизе устойчивость.
Поскольку у МакКоннела говорится уже о боевых версиях приложений, то,
выходит, в вашем случае приоритет отдан устойчивости.
А про дебаг — да, интересное замечание. Я думаю, мало кто будет против корректности в дебаге.
Хотя тоже есть нюансы — недавно столкнулись с тем, что из-за большой интенсивности ошибок, приводящих
в дебаг-версии к исключениям, отлаживаться стало невозможно. Пришлось сделать механизм временнОй
блокировки — когда пришедшее исключение запоминается в "чёрный список" и в течение некоторого времени
(например, одной минуты), все такие исключения игнорируются, т.е. добавляются только в лог, без прерывания
исполнения программы. Стало работать замечательно!
Здравствуйте, andy1618, Вы писали: A>А про дебаг — да, интересное замечание. Я думаю, мало кто будет против корректности в дебаге. A>Хотя тоже есть нюансы — недавно столкнулись с тем, что из-за большой интенсивности ошибок, приводящих A>в дебаг-версии к исключениям, отлаживаться стало невозможно. Пришлось сделать механизм временнОй A>блокировки — когда пришедшее исключение запоминается в "чёрный список" и в течение некоторого времени A>(например, одной минуты), все такие исключения игнорируются, т.е. добавляются только в лог, без прерывания A>исполнения программы. Стало работать замечательно!
в больших проектах я несколько раз видел, что в дебаге приоритет все-таки, именно из-за сложности отдалки, отдается устойчивости, а в консоль пишутся все проблемы корректности. но что я заметил — когда проблемы пишутся в консоль, а не раздражжают окошками, то никто не торопится их исправлять и часто так и пускают в релиз. мол, а, подумаешь, фигня какая-то, вроде все работает.
Но проблемы те же самые.
