Добрый день. Скажите можно ли реализовать в шарпе такую штуку?
М моем приложении будет журнал событий, в который записываются ошибки и все остальное, в наиболее важных и ключевых местах я естественно ставлю 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 - это хуже, чем сторонняя библиотека