Добрый день.

Какова политика разработчиков в плане обработки исключений?
Каковы рекомендации к использованию?

Исходя из кода если определен #define HANDLE_EXCEPTIONS то перехватываются ВСЕ исключения, заворачиваются в производный от RsdnDataException (который в свое очередь от Exception — но не от ApplicationException) и выбрасывается наверх.
Если произошло outofmemory или steckoverflow — дальнейшая работа приложения в общем-то невозможна...

И по поводу дефайна. По МСДН-у область видимости define это файл в котором он написан. Т.е. хитрым щелчком мыши переключатсья между хандлиногом эксепшенов снаскоку невыходит. Есть возможность указать компилятору — но не очень понятно где это указывать в студии для asp.net 2.0

Этот пост не вплане поругаться или пожурить, а плане понять политику

Спасибо.

Здравствуйте, dak_dak, Вы писали:

_>Какова политика разработчиков в плане обработки исключений?
_>Каковы рекомендации к использованию?

По последней версии политика такая. Перехватываются только исключения, возникающие в результате обращения к методам провайдера данных. Все они передаются в виртуальный метод OnOperationException, где заворачиваются в BLToolkit.Data.DataException и выбрасываются дальше. Это делается только лишь с одной целью — унифицировать обработку исключений от разных провайдеров данных. Все остальные исключения проходят как есть. Т.е. если во время вызова метода ExecuteObject произошло исключение в вызове метода IDbCommand.ExecuteReader, то оно будет завёрнуто в DataException. Если исключение возникло после, во время маппинга данных в объект, то вызывающая программа получит исключение как есть.

Метода OnOperationException виртуальный и имеет следующий вид:

protected virtual void OnOperationException(OperationType op, Exception ex)
{
    throw new DataException(ex);
}

Т.е. перекрыв его можно либо заменить тип исключения на свой, либо вообще оставить его без изменений.