Диез Automater
При вот таком вот коде:
Вы получите ошибку 'Ошибка при чтении файла'. Т.е., в общем случае, трудно установить на какой строчке произошла ошибка. А если каждую строчку "окальцовывать" try-catch'ами, то код будеть выглядеть пугающе.


Пример странный, никакого смысла такой код не несет. Ну да ладно... :)

Convert.ToInt32() и File.ReadAllText() (к примеру) будут выбрасывать совершенно разные типы исключений. Вот их и ловите по очереди, а в конце уже ловите общий Exception.Мой шеф, любитель как раз таки этого подхода, именно этим и занимается. Прелесно смотреть на его список "потенциальных ошибок", который, естественно, не включает в себя весь спектр возможных. Конечно в итоге он ловит "общую" ошибку, если остальные не подошли, но смшно смотреть на то как человек мучается. Потом он ещё начинает изобретать свои классы исключений. Ведь надо же "вывалиться" из программы аварийным способом не только когда строчка не конвертится в число, а когда и процедура обращающаяся к базе вернула пустое множество, т.е. в случае логической ошибки. Ох, как жешь Билли заставляет людей раскорячиваться!

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

Диез
Ну и что? Вы "оборачиваете" внешние исключения плюс логические ошибки - в коды возврата; он - их же оборачивает в бизнес-исключения, которые точно так же обрабатывает вызывающий код (совершенно необязательно вываливаться из программы при этом).
В чем разница-то?В том что у меня код короче! Вопрос в стоимости поддержки софта, т.е. о количестве времени требуемом новому (или старому, но забывшему) программеру на то чтобы разобраться с логикой процедуры. Если обработка события стоит в catch'е на несколько экранов ниже, то проггеру придётся не сладко. Например: видит он багу что программа запихала в лог, лезет в код, ищет catch, находит, над catch'ем - пара экранов кода, и поди пойми какая строчка вывалила ошибку! Допустим пришла "ошибка конветации в число", а команд ToInt32() несколько - которая из них сбойнула?
ДиезПохоже, вы на Java не писали никогда. Вот где заставляют, так заставляют Потому некогда и не пис а л

Вот сегодня опять напоролся на необходимость реализации упомянутой мною системы (вывод в лог не только места где рухнуло, но и всех входящих параметров в ту процедуру, где произошёл эксепшн). Вижу у себя в логе, что пользователь Х. получил ошибку "clsDALBase.SafeExecuteStoredProcedure: The error description is 'An invalid character was found in text content.'. Could not find prepared statement with handle 3. The statement has been terminated." Явно при запаковке введённых текстовых данных в XML-строку туда проскочил какой-то нехороший символ, при распаковке посчитавшийся за специальный (управляющий). Но КАКОЙ ИМЕННО?!

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

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