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

0K>2. Ошибки в коде программы (кривой код).
0K>Примеры: вышли за границу массива, обратились к защищенной памяти, вызвали из другого потока к потоконебезопасный метод.
Наверное эти ошибки можно разделить на нарушение контракта (метод вызывается с неверными параметрами) и нарушение инварианта (на каком-то этапе работы стало понятно, что состояние объекта испорчено).

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

0K>Начал думать над стратегией обработки исключений.
Но мне кажется эта "классификация" не имеет прямого отношения к обработке исключений.
По непосредственно обработке придерживаюсь следующих (очевидных?) правил:
1. Все исключения должны логироваться + как можно больше данных приведших к ним. Т.е. если была ошибка в базе данных то не плохо было бы видеть сам "плохой" запрос, данные по результатам которых он был сформирован и (на сервере) исходный входящий запрос. При тестировании можно, грубо говоря, запускать батник и проверять что до запуска приложения и после остановки лог пустой, очистка лога на совести человека.

2. Для пользователя надо постараться извернуться и показать какие именно его действия привели к ошибке и как её исправить. И здесь на самом деле не так важно системная ли эта ошибка или входных данных. На сервере разумеется нужно вернуть сообщение как можно менее раскрывающее внутреннее устройство и возможные уязвимости (на клиенте на самом деле тоже, но выбирая между удобством и паранойей я склоняюсь в сторону удобства).

3. Учитывать контекст ошибки. Если ошибка произошла при формировании ячейки таблицы, вряд ли имеет смысл показывать мессадж бокс на каждую из тысячи ячеек.

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

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