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

P>>По быстродействию я уже отписывался — им можно пренебречь. Если по этому поводу есть чего добавить нового из аргументов — то не стесняйтесь.
lpd>Ты приводил пример проекта POS-терминала, где тебе исключения помогли. Еще раз замечу, что это была не real-time система. Говорить, что быстродействием _всегда_ можно пренебречь — преувеличение.
Ок, перефразирую: в прикладной области стоимость исключений можно принять нулю.
Хотя, с другой стороны, хоть у меня и нет опыта в real-time системах но я подозреваю, что там лучшее место обработки проблемы — это место её возникновения. Потому потребности в исключениях там просто не возникает.


lpd>Исключения передают ошибку на несколько уровней вверх. Получается, что программист, разрабатывающий обработчик, должен познакомиться со всем, что в конечном счете вызывается и может выбросить исключение. По сравнению с постепенной пошаговой явной передачей ошибки на уровни вверх, или по сравнению с общими структурами данных, содержащих описание ситуации, код с исключениями получается короче, но сложнее.

Я вот про что: при работе с исключениями лучшей практикой является построение иерархий. И при работе с конкретным модулем можно ловить только базовое для модуля исключение, что избавляет от изучения их всех. А уже по потребности ловить специализированное исключение. Замена модуля на другой из дополнительных накладных расходов потянет только замену типов отлавливаемых исключений.

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