Как реализации интерфейса должны обрабатывать неожиданные внутренние исключения типов, которые могут ожидать вызывающие?

Если класс реализует интерфейс, как он должен обрабатывать ситуации, когда либо

1. При выполнении метода или свойства возникает внутренняя ошибка, которая имеет тип, который вызывающий может разумно ожидать но который, возможно, не должен. Например, IDictionary.Add делает что-то внутренне, что дает исключение ArgumentException при обстоятельствах, которые означают, что словарь поврежден, но не будет означать ничего плохого в остальной части системы? Или они подразумевают, что что-то повреждено за пределами словаря? Вызывающий может ожидать, что поймать и обработать тот факт, что в словаре существует дублирующийся ключ, поскольку в некоторых случаях исключение может быть Vexing (например, один и тот же код может использоваться для словаря, который не был доступен другим потокам и для ConcurrentDictionary который есть, и семантика будет работоспособна, если попытка добавить дублируемую запись вызовет чистый сбой). Предоставление прокрутки ArgumentException приведет к тому, что вызывающий агент полагает, что словарь находится в том же состоянии, что и добавление никогда не происходило, что может быть опасно, но бросание какого-либо другого типа исключений может показаться запутанным.
2. При выполнении метода или свойства возникает исключение, которое, возможно, должно или не должно обрабатывать вызывающий объект, а определение интерфейса не дает никакого намека на то, что может возникнуть любое исключение, связанное с удаленностью. Например, предположим, что что-то пошло не так в оценке IEnumerator, либо подразумевая (1), что перечислитель получил повреждение (возможно, неожиданным действием в другом потоке), но повторное перечисление может преуспеть; (2) сам перечислимый объект, вероятно, поврежден или непригоден для использования, но все остальное в системе, вероятно, хорошо (например, лениво оцениваемая процедура разбора файла попадает в недопустимую запись); (3) что-то вне перечислимого объекта было повреждено. IEnumerable имеет только одно определенное исключение, которое может вызывать, но вызывающий может захотеть изменить свое действие на основе "серьезности" исключения. Если бы у меня были мои барабанщики, система определяла бы такие типы, как RetryableFailureException, CleanFailureException, ObjectCorruptFailureException, и большинству интерфейсов было бы позволено бросить их или их производные. Так как это не так, как правильно обрабатывать интерфейсы либо из вида интерфейса, либо из вызывающего?

   BTW, один шаблон, который я не видел, реализовал, но, казалось бы, был бы полезен, было бы для методов принимать параметр делегата, который должен выполняться, в случае, если метод завершился неудачно, что приведет к тому, что метод "try" вернет false, Такой делегат, предоставленный вызывающим, мог тогда не только генерировать исключение, которое должен знать получатель, но также может установить флаг, который в противном случае был доступен только вызывающему. Таким образом, вызывающий может знать, что исключение, которое было поймано, действительно было ожидаемым.