Можно ли производить валидацию в сеттере свойства c#

Можно ли производить валидацию в сеттере свойства c#

Ответ

Вынесено из комментариев.

Да, валидацию присваиваемого значения с последующей генерацией исключения в сеттере производить допустимо.
Обратимся к известной книге "Framework Design Guidelines. Conventions, Idioms, and Patterns For Reusable .NET Libraries", раздел 5.2:
It is OK to throw an exception in a property setter. It is very much like setting an array element, which can throw as well (and not just then checking the index bound but the possibility of type mismatch between the value and the array element type).
Microsoft слово в слово цитирует эту книгу здесь. Кстати, в геттере генерировать исключения не рекомендуется.
А вот Дж. Рихтер в "CLR via C#" (гл. 10 "Свойства") высказывает негативное отношение к свойствам, указывая, что они часто обладают неожиданным для разработчика поведением:
Лично мне свойства не нравятся и я был бы рад, если бы в Microsoft решили убрать их поддержку из .NET Framework и сопутствующих языков программирования. Причина в том, что свойства выглядят как поля, являясь по сути методами. Это порождает немыслимую путаницу. Столкнувшись с кодом, который вроде бы обращается к полю, разработчик привычно предполагает наличие множества условий, которые далеко не всегда соблюдаются, если речь идет о свойстве. [...] Свойство, являясь по сути методом, может выдавать исключения, а при обращениям к полям исключений не бывает. [...] Свойство-метод может выполняться довольно долго, в то время как обращения к полям выполняются моментально.
Полностью отказываться от свойств, пожалуй, не стоит, но разумно управлять сложностью их логики необходимо. Добавление в сеттере проверки на null, проверки на диапазон допустимых значений и т.п. с генерацией исключения будет хорошей идеей. А обращаться в свойствах к БД, выполнять длительные вычисления, запускать и блокировать потоки и т.д - уже нет.
Если дополнительные действия выполнять все же нужно, преобразуйте ваше свойство в метод.
Другими словами, в свойстве не следует производить действия, нарушающие принцип наименьшего удивления (этот принцип относят к пользовательскому интерфейсу, но к публичному API он тоже вполне применим).