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

git>Наверное эти ошибки можно разделить на нарушение контракта (метод вызывается с неверными параметрами) и нарушение инварианта (на каком-то этапе работы стало понятно, что состояние объекта испорчено).

Спасибо за подсказку. Попытку записи в защищенную память отнести к нарушению инварианта? Или попытку привести объект к несовместимому типу?

git>Но мне кажется эта "классификация" не имеет прямого отношения к обработке исключений.

Еще как имеет. Дело в том, что к каждой из групп применяются схожие правила обработки. Как я уже сказал -- аппаратные ошибки (системные) -- на уровне средней программы исправить скорее всего не удастся. Так что аппаратные ошибки в 90% случаев никак не обрабатываются. Ошибки нарушения контракта/инварианта однозначно говорят о кривости кода (без вариантов). Ошибки связанные с корректностью/правильной последовательностью данных уже связаны с внешним источником -- причин может быть множество.

Четкая структуризация -- залог успеха.

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

Еще подумайте как сделать так, чтобы в лог не попали приватные данные (если финансовая система).

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

Внимание! Действие пользователя не может привести к системной ошибке. Только к ошибке данных.

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

Дело даже не в разрешении ситуации на лету по базовому классу (хотя и это возможно иногда) а в лучшей СТРУКТУРИЗАЦИИ. Это очень важно.

Ошибки кода, к примеру, можно сразу отправлять разработкчику. Это 100% его вина. А вот ошибки работы с данными -- под вопросом. Можно даже детали вывести пользователю -- не все дураки, многие поймут в чем дело.