Всем привет. 

Заметил, что совсем не умею обрабатывать эксепшены :( 

1) В 90% случаев просто логирую и/или показываю юзеру // т.е. ничего толкогового с информацией об ошибке не делаю.
2) Любимый catch блок -- catch (Exception ex) // А как же обрабатывать только конкретную ошибку?
3) Больше в голову ничего не приходит, но есть четкое ощущение, что я с эксцепшенами не дружу :( 


Что можете посоветовать, уважаемые форумчане?

Зарание спасибо, ivashkanet.

P.S. Если кто считает, что но еще! не "уважаемый" форумчанин -- спешу его поправить, для меня важно мнение каждого!

Я не философ, но свое мнение имею ... и его выскажу   


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



каждый конкретный exception - класс, производный от базового Exsception (например ArgumentException, InvalidOperationException и т.д.) поэтому и ловить нужно несколькими catch-ами 

это не только удобочитаемо и культурно... каждый из классов Exception-ов имеет свои поля и свойства для дополнительной информации об ошибке, которых нет в базовом (иначе зачем создавать потомков, не так ли?). Если же у тебя какая-то кустомная ошибка может быть - создавай свои классы Exception-ов, я так часто делаю... Создаю свой класс Exception-а, который, к примеру, имеет поля типов DataRow, DataColumn, SessionId и т.д. и т.п. И если где-нибудь в иерархии происходит исключение и мне удается привести его к классу своего exception-а ... то польза от этого становится весьма и весьма ощутимой...

К тому же порядок catch-ей важен, поскольку они обрабатываются в порядке указания их в коде. В моем примере если ты перенесешь catch(Exception ex) наверх, то он "закроет" исключения (потому как полиморизм исключений сработает) и catch (ArgumentException ex) будет всегда недостижим, а вместе с ним - и вся твоя дополнительная информация.



ммм... надо батенька, надо. 
действительно хорошие статьи:
рекомендации по обработке исключений
Exception Management Architecture Guide

Это сообщение отредактировал(а) tol05 - 18.3.2008, 12:00

tol05, эхххььь, это теория. Я это все знаю :( Мне бы применять научиться...


Это я делаю, но неужели это все? Не верю! 
Можно ведь проанализировать эксепшен и, если это возможно, вернуться в начало, возможно что-то исправить, и повторить попытку (Server unaccessible)...

Эт тоже в курсе  

А вот за статьи реально спасибо!

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

Прочитал первую. Очень неплохой экскурс в правила "хорошего тона". Большое спасибо. 
Вторая -- многа букафф, отметил к прочтению.

Пролистал вторую --- ИМХО, то что мне надо! 
Но почему же так много букаффф     
Перенес "к прочтению" на "к прочтению сегодня на ночь"   

а что? мало?  



Исправить и вернуться - нельзя, т.к. исключение выбрасывает тебя их стека выполнения (стек очищается, кто его второй раз заполнит?). 

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

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

Как-то да  Я же говорю не до конца понимаю принципы  


Да, я когда писал понял, что это почти невероятная ситуация (именно поэтом у меня так много "возможно" 

Прочитал. То что надо   Где бы еще опыта получить...  

Выжимки:

Когда ловить исключения:


Требуемая информация по группам "пользователей":


Как получить требуемую информацию в коде:


Каждое приложение должно ловить исключение до того как оно попадет к конечному пользователю!
Для этого используют:
ASP .Net 
Cекцию customErrors файла web.config:

Дерективы конкретной страницы:

Код:


Самостоятельное приложение:


Так-то вот ;-)

Вот еще интересная статья
http://blogs.msdn.com/kcwalina/archive/200...ierarchies.aspx

Лол, приехали,  закрывать ресурсы надо в блоках finally!!!


ivashkanet Вот тебе несколько философских аксиом для размышлений:
1) Исключения можно генерировать только в исключительных случаях, никогдане используй исключения для управления потоком выполнения.
2) Исключения должны перехватываться только в том месте, где они могут быть обработаны с уровнем знаний достаточным для того, чтобы справиться с исключением наилучшим образом, например, выполнить откат.
3) Надо стремиться писать нейтральный к исключениям код, под этим понимается что ты сначала выполняешь тот код, который потенциально может генерировать исключение, и только потом фиксируешь изменение состояния при помощи операций 100% не генерирующих исключения.

что скажете насчет проброски иключений ?

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

Во некроманты   
source777, за это время я столько литературы перелопатил... в том числе и про исключения.
Тем более Exception Management Architecture Guide ответила на все мои вопросы.

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

А я чё, я ничего... это QryStaL... да и прошло то меньше 3 месяцев... не 3 года всё-таки.



Ошибаешься, там очень полезная методика описана.

В том то вся и фишка, фиксирование состояние производится операциями, которые гарантировано не генерируют исключений, например, присваивание ссылок. Для подобных методов даже спец. атрибут есть [ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)]

Грамотно применяя эту технику, можно писать нейтральный к исключениям код с минимальном кол-вом блоков try/catch... и возможностью отката при возникновении исключения.

Ну так переубеди меня  


Опять ничего не понятно.  
Раз затронул эту тему развивай ее: давай ссылки, примеры, ... ;-)

Добавлено через 1 минуту и 16 секунд
QryStaL, спасибо за статью, но "Exception Management Architecture Guide" все же покруче будет.

Согласен. Эта статья просто в дополнение темы.