Добрый день. Скажите можно ли реализовать в шарпе такую штуку?
М моем приложении будет журнал событий, в который записываются ошибки и все остальное, в наиболее важных и ключевых местах я естественно ставлю try {}, но каждую строчку не выделишь, а ошибку может произойти там где меньше всего ее ожидаешь. Так вот вопрос: можно ли сделать такую функцию, которая перехватывала бы любой исключение необработанное блоком try?

Если у тебя windows-приложение (я предполагаю), то можешь написать в Program.cs:

я уже поднимал когда-то такой вопрос на форуме:
http://forum.vingrad.ru/forum/topic-231495.html

Рихтер, как справедливо замечено в той теме, не рекомендует так поступать: приложение не должно "проглатывать" все исключения подряд. исключение как раз для того и предназначено, что означает исключительную ситуацию. по-хорошему, каждое исключение нужно отлавливать по-своему, потому что в разных местах логика работы программы (и соответственно логика обработки ошибок) разная. задача "поймать все исключения и по возможности молчаливо продолжить работу" актуальна только в том случае, если вам достался недорелиз, который завтра надо показывать заказчику, а в нем багов немеряно. в остальных ситуациях просто надо ловить ошибки в тех местах, где они могут быть, вот и все

AppDomain.UnhandledException Event и остальные методы в его Remarks. Перед использованием прочитать документацию и Exception Handling Guidelines

Добавлено через 3 минуты и 21 секунду
ЗЫ elbjarn, работает в .NET Compact Framework ;)

PashaPash, 
Насколько я знаю, AppDomain.UnhandledException Event не произойдёт, если исключение будет брошено в каком-нить "левом" потоке приложения....

Partizan, про левый поток - это Application.ThreadException

ааа...точно...

Вообще, по идеи, программист должен знать где у него может возникнуть исключение и реализовать его соответствующую обработку...

Заворачивать все подряд в try - catch не разумно..   



Это интересно как? Когда вызываешь метод, в котором написано какие исключения он может выбросить и не ожидаешь, что выбросятся исключения?

Я думаю нету смысла оборачивать в try-catch места кода, где идут операции типа Console.WriteLine("любой текст")... 

Ну а


Вообще отжег ))

А чего не так:



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

В MSDN не перечислены все возможные исключения для методов, только специфические для них. ThreadAbortException, BadImageFormatException, TypeLoadException, OutOfMemoryException и еще н-цать других могут возникнуть в любой момент. Поэтому нужно действовать строго по гайдлайнам - ловить только те исключения, после которых код может восстановиться - продолжить нормальную работу.
Вообще,  исключение - это не ошибка. Это уведомление о том, что какое-то предположение, сделанное разработчиком в момент написания кода, оказалось ложным.  Например, вызов File.Move предполагает что файл существует. Поэтому нельзя "ожидать, что выбросятся исключения". Выбросилось исключение - значит ты уже не ожидал ситуации, которая его вызвала. 

Как это возможно?! Все что ты пишешь, должен ожидать возможную непредвиденную ситуацию (если весь проект - твой и не используются сторонние библиотеки) и обрабатывать ее. Что значит в "любой момент"? Все обработано и записано в лог. В тех местах, где это нужно, а не везде подряд, чтобы авось не вышла какая нибудь исключительная ситуация.. Тут нету авось, это ж как в аптеке  да - да, нет - нет.



Интересное утверждение. Исключение это следствие ошибки программиста в некоторых случаях, а значит косвенно тоже ошибка ))))))))



Не обязательно, ведь есть ожидаемые исключения?! Ты ждешь что возможно получишь исключение, знаешь какое, на всякий случай убеждаешься, что это именно оно, а то еще и предварительно сам его throw делаешь =))) Почему ложным?! Если заготовлена обработка?



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

Вообще исключения и их обработка дорогостоящая и ресурсоёмкая, поэтому ими и нужно пользоваться в ИСКЛЮЧИТЕЛЬНЫХ ситуациях а не оборачивать все приложение в try - catch..

Думаю пора эту тему в песочницу переносить =)))

ЗЫ.
Оберни хоть весь комп в трай - кэч, если возникнет OutOfMemoryException смысл уже удерживать работоспособность приложения?!?!?!

PS.

А если возникнет:  .NET Runtime version 2.0.50727.63 - Fatal Execution Engine Error ??? Сколько не оборачивай траями, все равно прилада сляжет =((( А на траях тока производительность потеряешь! 

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



Использовать так:



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

Мурлыкатам_, 



А .NET считается сторонней библиотекой?   



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

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



так почему предположение программиста - ложное?!   

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

Мурлыкатам_, 



Да потому, что предполагает программист, что метод отработает нормально...
Брошенное  исключение говорит, что "видимо что-то случилось"(с) не помню кто.

В любой момент - дословно - значит вообще в любой момент. .NET обладает замечательным свойством бросать исключения прямо посреди твоего кода. ThreadAbortException в строчке i++? Да как два пальца  В примере выше можно ожидать исключения между словами Main и первым try - там есть nop, в отладочной сборке. Ожидать исключения можно вообще в любой момент, но это не значит что каждую строчку надо заворачивать в try/catch. Есть вполне определенные места, где исключения есть смысл ловить - на границе уровней приложения. В документации к Exception Handling Application Block есть очень наглядная картинка. Все остальные try/catch можно почти всегда смело выбросить.

Исключение - следствие неидеальности мира  Скажем, тот же ThreadAbortException в веб-приложении - не ошибка, и при этом код не может и не должен продолжать выполнение. 
Если можно заменить ожидание исключения предварительной проверкой - то нужно это сделать. А если ты сам делаешь throw и сам тут же ловишь это исключение - то налицо явные проблемы с дизайном. Ловить и обрабатывать можно только чужие исключения, в крайнем случае - свои из другого независимого куска.
Ну да, их всего то штук 40  И что ты понимаешь под обработать? Восстановиться после ошибки и продолжить нормальное выполнение? Код пытался переместить файл, не смог. Если он после этого может нормально работать, то зачем он перемещал файл? Если не может - то какой смысл обрабатывать исключение? Записать в лог, и спокойно умереть, бросив оригинальное исключение - правильный выбор в 99% случаев. И с этим вполне справляется один глобальный стандартный обработчик на все приложение.

Добавлено через 1 минуту и 39 секунд

Сегодня вышел GDR к .net 3.5 SP1, исправляющий пару критических ошибок.  .net - это хуже, чем сторонняя библиотека 

отжег ++           

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

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

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

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

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, который отлично стыкуется с логгингом из той же библиотеки.