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

0K>Попытку записи в защищенную память отнести к нарушению инварианта?
В большинстве случаев наверное — да

0K>Или попытку привести объект к несовместимому типу?
Здесь уже возможно больше разнообразия — если сигнатура интерфейса скажем требует object, а мы пусть и не явно ожидаем что будет передан Button, то передача чего-то другого — нарушение контракта.

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

0K>Внимание! Действие пользователя не может привести к системной ошибке. Только к ошибке данных.
Сходу — попытка открыть слишком большой файл и OutOfMemory, извлечение диска во время прожига, отключение сетевой папки во время работы. это все разве не приводит к системным ошибкам?

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