Документирование Интерфейсов и их [закрытой] реализации
AFAIK Visual Studio Express не идет с поддержкой на 64 бита.
2 ответа
Я не уверен, что полностью понял ваш вопрос (и я разработчик на Java, а не на C #), но, похоже, вы спрашиваете, в чем, по сути, проблема полиморфизма: если кто-то использует метод интерфейса, который, как объявлено, генерирует X и Y, что произойдет, если реализация выбрасывает Z?
Следует следовать принципу соответствия, который, по сути, гласит, что подтип должен соответствовать поведению супертипа. То есть, если вы документируете, что ваш метод в интерфейсе может генерировать исключения только одного типа (например, исключения с нулевым указателем), то ваш контракт с вызывающими абонентами заключается в том, что это единственное, на что им следует обратить внимание. Если вы бросите что-нибудь еще, вы можете удивить их.
Документирование конкретного подтипа в супертипе - не лучшая идея, поскольку это создает ненужную связь. Меня больше беспокоит тот факт, что реализация может вести себя иначе, чем декларация, поскольку это может означать, что декларация недостаточно конкретизирована.
Постарайтесь подумать, какие типы исключений может вызывать ваш метод. Создайте для них супертипы, а затем явно объявите в своем интерфейсе метод (например, этот метод может вызвать какое-то «исключение вычисления»). Затем в своей реализации сгенерируйте исключение вычисления с более подробной информацией или вызовите какой-либо подтип исключения вычисления, специфичный для реализации, вы все равно будете соответствовать.
Постарайтесь подумать, какие типы исключений может вызывать ваш метод. Создайте для них супертипы, а затем явно объявите в своем интерфейсе метод (например, этот метод может вызвать некое «исключение вычисления»). Затем в своей реализации сгенерируйте исключение вычисления с более подробной информацией или вызовите какой-либо подтип исключения вычисления, специфичный для реализации, вы все равно будете соответствовать.
Постарайтесь подумать, какие типы исключений может вызывать ваш метод. Создайте для них супертипы, а затем явно объявите в своем интерфейсе метод (например, этот метод может вызвать какое-то «исключение вычисления»). Затем в своей реализации сгенерируйте исключение вычисления с более подробной информацией или вызовите какой-либо подтип исключения вычисления, специфичный для реализации, вы все равно будете соответствовать.
Я согласен со всем, что говорит Ури - вам следует, где это разумно, создавать собственные исключения, которые при необходимости могут быть расширены, тогда метод, использующий параметр, введенный в ваш интерфейс, может перехватить это исключение, а также подтипные исключения.
Дон ' Но создавать их без нужды, если они существуют. Net Framework, описывающее ваше состояние ошибки, используйте это
С точки зрения документирования для разработчиков, вы можете использовать раздел комментариев в комментариях (при условии, что вы используете XML-комментарии), чтобы описать такие вещи, как вы ожидаете от разработчиков. . Очевидно, это никоим образом не подлежит принудительному исполнению, но может служить полезным руководством, когда разработчик прибегает к использованию вашего API