Я действительно пытаюсь выяснить лучшие практики для многоразового кода, который легко отлаживается. Я наткнулся на обычную практику среди разработчиков, что я пока не совсем понимаю.
public MyConstructor(Object myObject)
{
if (myObject == null)
throw new ArgumentNullException("myObject is null.");
_myObject = myObject;
}
Кажется излишним делать эту проверку. Но я думаю, что это потому, что я не совсем понимаю, что преимущества этой проверки. Кажется, что в любом случае будет выбрано исключение с нулевой ссылкой? Я, вероятно, ошибаюсь, мне очень хотелось бы услышать некоторые мысли об этом.
Спасибо.
Для компилятора null является допустимым аргументом конструктора.
Ваш класс может обрабатывать нулевое значение для myObject. Но если он не может - если ваш класс сломается, когда myObject равно null, тогда проверка в конструкторе позволяет быстро выполнить..
Передача объекта null вполне законна во многих случаях - для этого класса разработчик хочет убедиться, что вы не можете создать экземпляр класса без передачи действительного экземпляра Object, хотя, следовательно, должны быть никаких проверок позже - это хорошая практика, чтобы обеспечить это как можно раньше, что было бы в конструкторе.
если вы под 4.0 можете сделать следующее:
public ctor(IEnjection ninjaWeapon)
{
Contract.Requires<ArgumentNullException>(ninjaWeapon != null);
this.deadlyWeaponary.Add(ninjaWeapon);
}
если вы используете более старую версию, обратитесь к Microsoft.Contract, чтобы сделать то же самое.
Компилятор понятия не имеет о значении объекта, поэтому вам нужно проверить это во время выполнения, чтобы он не вызывался с нулевым значением.
Это также зависит от вашего конкретного решения. Вам не нужно бросать исключение, я бы просто выбросил его, если вы не можете иметь это значение равным null, а если оно равно null, это исключительный случай.
Я думаю, что вообще невозможно сказать, нужна ли проверка нулевого или нет. Это скорее зависит от того, можете ли вы жить с нулевыми переменными или нет. Нуль - это не само по себе плохое состояние. Возможно, у вас могут быть ситуации, когда допускается, чтобы переменная была нулевой, а другая - там, где она отсутствует.
Спросите себя, имеет ли смысл разрешать нулевые значения или нет и соответственно проектирует конструктор.
Вы можете реализовать простой метод расширения ThrowIfNull, чтобы уменьшить код, который вы пишете каждый раз. Джон Скит рассказал об этом в своем блоге и ссылочной SO статье здесь.
Вам нужно явно проверить значение null, потому что компилятор не знает, но также потому, что null может быть допустимым аргументом.
Преимущество заключается в том, что исключение будет выбрано при создании объекта, поэтому вы можете легко проследить, какая часть кода является виновником. Если для вашего кода требуется ненулевое значение myobject, и вы не проверяете его в конструкторе, то NullReferenceException будет выбрано при использовании myObject_, и вам нужно будет отследить его вручную, чтобы узнать, кто отправил это нулевое значение в.