Итак, я слышал, что проверка значения в таком свойстве:
//dummy example, let's assume that I want my value without dots
public string MyProp
{
set
{
if(value.Contains('.'))
throw new ArgumentException("Must not contain '.'", "value");
}
}
неправильно, и я должен избегать этого.
Но раньше мне говорили, что это хороший способ. Мы могли бы использовать инкапсуляцию, есть только одно место для проверки, СУХОЙ и т. Д.
Что не так с моим маленьким примером?
Нет ничего плохого в том, чтобы генерировать исключения в установщике свойств. Но вы должны бросить ArgumentException, а также установить значение свойства!
private string _myprop;
public string MyProp{
set{
if(value.Contains('.')) throw new ArgumentException("Must not contain .");
this._myprop=value;
}
get { return this._myprop; }
}
Из статьи о передовых методах работы в MSDN:
Получатели свойств должны быть простыми операциями без каких-либо предварительных условий. Если получатель может вызвать исключение, подумайте о том, чтобы преобразовать свойство в метод. Эта рекомендация не относится к индексаторам. Индексаторы могут вызывать исключения из-за недопустимых аргументов.
Допустимо и допустимо генерировать исключения из средства задания свойств.
Есть еще несколько подобных вопросов по SO.
Вы должны быть максимально легковесными. И если сеттеры выдают ошибку, это нормально, но, опять же, вы можете подумать о переносе ее в функцию. Все может легко запутаться.
ИЗБЕГАЙТЕ исключения исключений из методов получения свойств. Получатели свойств должны быть простыми операциями и не должны иметь предварительных условий. Если геттер может генерировать исключение, его, вероятно, следует переделать в метод.
Рекомендации: выбрасывание исключений из свойств
Какое исключение генерировать из установщика свойств?
См. Рекомендации: создание исключений из свойств для объяснения и обсуждения почему выбрасывать исключения из свойств - это плохо.
По общему признанию, этот пост говорит о получателях собственности.
Сеттеры обычно рассматриваются потребителями как просто устанавливающие частное поле, скрытое свойством, и, возможно, выполнение некоторых дополнительных действий по мере необходимости, исключения - это неожиданное поведение, и вы можете представить, что нужно заключить каждый оператор набора внутри блока try?
Хотя это может быть приемлемым поведением в соответствии с рекомендациями, это кошмар для разработчиков, и логика проверки должна содержаться в отдельном методе, а затем при необходимости вызываться из свойства.
Если вам нужна проверка или особое поведение при настройке свойств, вы должны использовать метод set, например. SetMyProp(string value), поскольку это дает различие, что это может привести к исключению и т. Д.
Если вы используете свойства для чего-то вроде модели WPF, вам следует вместо этого использовать встроенную проверку данных WPF.
try вокруг каждого оператора set сродни использованию блока try вокруг каждого Substring, потому что ваш начальный индекс может выходить за границы. Просто проверьте данные.
- person Ry-♦; 08.04.2013
Contract.Requires(value != null); очень важно.
- person Matthew Watson; 08.04.2013
ArgumentException, б) вы фактически забыли установить значение! - person Julián Urbano schedule 08.04.2013