NotSupportedException- это плохая практика?
Собственно вопрос в том, а на сколько правильно использовать NotSupportedException?
Обычно, это используется в интерфейсах, когда отдельная фича может быть не реализована.
Не проще ли сделать отдельный интерфейс без необходимого метода?
Ответы (1 шт):
В случае, если метод не реализован применяют всё же NotImplementedException, NotSupportedException используется, если какой-либо функционал, предусмотренный контрактом или базовым типом не может быть реализован. Например, в BCL есть базовый абстрактный тип Stream, у которого есть метод Seek, устанавливающий позицию в потоке. Этот метод прекрасно работает с MemoryStream и FileStream, но, например, в NetworkStream -- нет, что абсолютно логично. Соответственно, в случае вызова метода Seek у объекта этого типа выбросится как раз NotSupportedExcption, то есть мы как бы говорим: "Бро, мы бы с радостью реализовали, но в данном случае это невозможно/не нужно", тогда как NotImplementedException чаще всего говорит о том, что функционал не реализован на данный момент, например, когда только-только появился Mono, в нем это исключение бросала добрая половина методов.
Касательно правильности использования могу высказать лишь мнение. Я считаю, что правильность зависит от контекста использования, то есть, да, стоит следовать принципу "I" из SOLID и разделять интерфейсы: раз чего-то нельзя делать, то не надо давать и такой возможности, принципу "L", кстати, тоже не очень хорошо от такого поведения типов-наследников. Однако, есть случаи, когда сделать это невозможно или затруднительно, есть много уже написанного кода в библиотеках и фреймворках, есть огромное количество оберток над низкоуровневыми системными вызовами, тот же класс Stream, в котором, кстати говоря, есть свойство CanSeek и это -- хорошо и правильно.
Резюмируя, имхо, есть случаи, когда без его использования не обойтись, но использовать его в новом коде, а тем более в коде бизнес-логики, думаю не стоит.