Контракты об ошибках WCF в реальном мире

Предположим, у нас есть метод службы, который выполняет некоторые проверки безопасности, извлекает данные из БД и сторонней веб-службы, создает MyDataDTO , записывает контрольную запись обратно в БД. И нам нужны хорошо структурированные, детализированные коды ошибок, не так ли? Мы хорошие мальчики и следуем стандартным правилам обработки ошибок WCF:

[FaultContract(typeof(AccessDenied))]
[FaultContract(typeof(KeyNotFound))]
[FaultContract(typeof(WsFault))]
[FaultContract(typeof(DbFault))]
MyDataDTO GetData(string key);

Теперь мы добавляем новый метод, который обновляет данные. Метод вызывает GetData () внутри (или его большую часть), выполняет проверку и обновляет данные. Таким образом, все ошибки GetData () должны быть продублированы плюс добавлены собственные ошибки:

[FaultContract(typeof(InvalidState))]
[FaultContract(typeof(DataNotValid))]
[FaultContract(typeof(AccessDenied))]
[FaultContract(typeof(KeyNotFound))]
[FaultContract(typeof(WsFault))]
[FaultContract(typeof(DbFault))]
void UpdateData(MyDataDTO data);

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

Теперь представьте, что у нас есть 10 сервисов с 10 методами, как указано выше (или даже более сложными) каждый. И определение всех этих контрактов сбоев становится кошмаром, поскольку это весьма подверженный ошибкам процесс:

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

Давайте не будем здесь учитывать версионность интерфейса :)

Итак, вы получили картинку если вы поддерживаете сервисы WCF в производстве. Должны ли мы вообще отказаться от контрактов на сбой и использовать старый добрый стиль C (например, иметь базовый класс DTOBase со свойством ErrorCode)? Уменьшить степень детализации ошибок? Как убедиться, что документация верна / актуальна? Меня интересуют лучшие практики.