отжег ++           

Чорт, нужно бежать... 

Отличная тема была бы для песочницы   

Ууууухх, завтра подебаширим )

В моем понимании обработать - это:

1) Программным путем понять что случилось;
2) Если то что случилось - совсем плохо - записать в лог или выдать пользователю предупреждение (или вообще непонятно, что случилось);
3) Если то что случилось приемлемо и ожидалось как возможная ситуация - принять соответствующие действия. К примеру закрыть соединение с базой. Отключиться от сайта и так далее. Я думаю тут не стоит особо разглагольствовать =)
4) По необходимости проинформировать пользователя или команду разработчиков путем отправки e-mail, как вариант. У нас в проекте так и делается. Все опасные ошибки отправляются e-mail ом со всей необходимой информацией, чтобы понять, что произошло. Очень удобно.
5) Если возможно восстановить работоспособность приложения.



А если у меня делается throw пользовательских исключений? Собственных? Который за счет выкидывания их попадают в общую систему обработки исключительных ситуаций??? Почему не делать throw?
При 3х кратной рекурсии, допустим в анонимном методе возникла проблема, как остановить выполнение этого куска кода??? Быстро???
Делать везде return false?! Это ж скока тогда проверок добавиться на возвращаемое значение, а тут делаешь:



И обрабатываешь, как тебе нужно..   



Касаемо File.Move я насчитал всего 8. Все весьма красноречивые, с помощью которых очень просто объяснить пользователю, какая проблема произошла. =)



No operation не выкидывает исключений   

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

Общая система обработки - явно не часть бизнес-логики, не часть доступа к данным, и вообще не часть какого-либо слоя приложения. Это часть среды, в которой приложение выполняется. И ловит она "чужие" исключения других уровней приложения, а не свои собственные.
Возникла проблема при 3-х кратной рекурсии в анонимном методе - о ужас. И что с ней может сделать вызывающий код? Фактически, метод не отработал. Вызывающему коду не нужен результат мегаметода? Зачем он тогда его вызывал? Просто так, позырить как тот упадет?  Приведи конкретный пример, а то я за все время не видел кода, где проверить возвращаемое значение было бы сложнее чем обработать исключение.
Исключение - это когда какой-то кусок кода не может продолжить выполнение. Совсем не может. И нормальный результат тоже вернуть не может. И все, кто он него прямо зависят - тоже не могут. А то, для чего ты хочешь их использовать - это забивание гводзей микроскопом.
Ок, приведи список. SecurityException в этом списке есть?

Есть? Тогда какого из еще 8-ми указанных в мсдн там нет?
На самом деле еще штук 20 красноречивых типово экспшенов можно смело из File.Move извлечь, и ожидать их все, и обрабатывать для каждого вызова File.Move - бессмысленно. Один глобальный обработчик - наш выбор 

Поправка - ты не знаешь что No operation выкидывает exception-ы. А вот .net после слова Main и до try может выбросить такого... StackOverflow при выделении памяти для локальных переменных - как раз перед try. PolicyException - ну вот вызывает твой метод что-то незаконное, и дотнет упадет вообще не в нем, а при попытке загрузить сборку с твоим кодом, с многозначительной ошибкой "Required permissions cannot be acquired". SecurityException - да вообще на любой строчке.
Самописная глобальная система регистрации ошибок - или миф, или велосипед. Есть стандартные средства, EntLib, подробная документация где и что ловить, когда и что перебрасывать, когда бросать свои исключения. Есть стандартные методы даже для отправки почты в по событию в EventLog.

Код пожалуйста, который его вызывает.

UnauthorizedAccessException подойдет?   

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



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

Пример:

Класс контроллер, ThreadsManager, запускает N потоков Thread1...ThreadN.

Каждый поток идет на определенный веб узел и допустим проверяет почту и отвечает на сообщения.
Если из потока выкинуть исключение куда оно полетит? Потом это исключение можно будет найти в журнале событий виндовса =)))
Нужно делать в каждом потоке свой обработчик, чтобы проблемы одного потока не касались в целом всего приложения и не нарушали работоспособность остальных потоков. (допустим один из сайтов банально недоступен, значит поток обработает исключение (operation has timed out) оповестит о том, что сайт не доступен (и к примеру пойдет на другой сайт), и будет потиху делать попытки до сайта достучаться, пока тот не поднимется) 
[я завтра хорошенько продумаю пример и продолжим спор предметно]   

Логично? Глобальный обработчик тут уже совсем пролетает, или нет? =)
Если приложение однопоточное, то может быть 



Очевидно! 



Это должно быть обработано?
Или вы поставляете заказчикам дебаг версии проектов???   С соответствующей обработкой?   

Это сообщение отредактировал(а) Мурлыкатам_ - 19.12.2008, 19:02

В Wpf Browser Application

Или любой похожий код, запущенный не под full trust. И при чем тут вообще UnauthorizedAccessException? Бросается SecurityException, в списке официально бросаемых его нет. Фактически, до этого поста ты даже не знал, что этот ексепшн может быть выброшен File.Move, и явно не собирался его обрабатывать.


А восстановление работы приложения почти никогда не возможно. По твоему примеру: ThreadManager должен быть в одном уровне приложения. Код, непосредственно работающий с почтой внутри одного потока - в другом. Между ними должен стоять глобальный обработчик для уровня. И принимать решение - что делать дальше, идти на другой сайт, или стучаться в тот же, должен не отдельный поток, а тот самый manager. Поток в случае исключения должен спокойно умереть, а глобальный кетч в этом уровне - оповестить манагера об ошибке, или упасть в jit при конкретном типе исключения, в случае отладки. Для этого в EntLib правила обработки вынесены в конфиг. Но позволять самому глуканувшему потоку определять свою судьбу - неэффективно, у него ж нет целостной картины происходящего.


StackOverflow прекрасно возникает и в релизной конфигурации, и, да, это должно быть обработано и записано в лог. А что, ваши приложения умирают без следов, если падают не в тех местах, где ожидалось? Т.е. если сейчас где-то в дебрях твоего проекта выпадет SecurityException на File.Move, то проект ничего в логах не оставит? Have a nice debugging 

Это сообщение отредактировал(а) PashaPash - 19.12.2008, 19:29

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

Да и 3й фрэймворк я даже еще в глаза не видел :((

Может разработаем парадигму обработки исключений в проектах
любой сложности? от простого до космического.. 

Мурлыкатам_ в этом посту уже давали очень неплохую ссылку.. http://forum.vingrad.ru/index.php?showtopi...t&p=1688591

Мурлыкатам_, еще есть готовый Exception Handling Application Block, который отлично стыкуется с логгингом из той же библиотеки.