Проверка Null в конструкторе

Я действительно пытаюсь выяснить, лучшие практики для многоразовый код, который легко отладить. Я столкнулся с распространенной практикой среди разработчиков, которую я еще не совсем понимаю.

public MyConstructor(Object myObject)
{
    if (myObject == null)
        throw new ArgumentNullException("myObject is null.");
    _myObject = myObject;
}

кажется почти ненужным делать эту проверку. Но я думаю, это потому, что я не совсем понимаю, в чем преимущества этой проверки. Похоже, что исключение null reference будет выброшено в любом случае? Я, вероятно, ошибаюсь, действительно хотел бы услышать некоторые мысли он.

спасибо.

9
c# exception-handling null

8 ответов

компилятору,null является законным аргументом конструктора.

ваш класс может обрабатывать нулевое значение для myObject. Но если это невозможно - если ваш класс сломается, когда myObject равно null - тогда проверка в конструкторе позволяет не быстро.

19

передает null объект во многих случаях является абсолютно законным - для этого класса разработчик хочет убедиться, что вы не можете создать экземпляр класса без передачи действительного Object экземпляр, поэтому позже не должно быть никаких проверок - это хорошая практика, чтобы обеспечить это как можно раньше, что было бы в конструкторе.

3

Если вы под 4.0 вы можете сделать следующее:

 public ctor(IEnjection ninjaWeapon) 
 {
     Contract.Requires<ArgumentNullException>(ninjaWeapon != null);
     this.deadlyWeaponary.Add(ninjaWeapon);
 }

Если вы в более старой версии, обратитесь к Microsoft.Контракт на то же самое.

2

компилятор понятия не имеет о значении объекта, поэтому вы должны проверить это во время выполнения, чтобы убедиться, что он не вызывается с нулевым значением.

Это также зависит от вашего конкретного решения. Вам не нужно бросать исключение, я бы только бросил его, если вы не можете иметь это значение null, и если оно равно null, это исключительный случай.

1

Я думаю, что вообще невозможно сказать, нужна ли проверка на null или нет. Это скорее зависит от того, можете ли вы жить с нулевыми переменными или нет. Null не является плохим состоянием. У вас могут быть ситуации, когда для переменной разрешено значение null и другие, где это не так.

спросите себя, имеет ли смысл разрешать значения null или нет и соответствующим образом проектировать конструктор.

1

вы можете реализовать простой ThrowIfNull метод расширения, чтобы уменьшить код, который вы пишете каждый раз. Джон Скит покрыл это своим блог и ссылка на статью SO здесь.

1

вы должны явно проверять на null, потому что компилятор не знает, но и потому, что null может быть аргументом.

0

благо, что исключение будет выброшено во время строительства объекта, так что вы можете легко проследить, какая часть кода является виновником. Если ваш код требует non-null myobject значение, и вы не проверяете его в конструкторе,NullReferenceException будет брошен, когда вы используете myObject_ и вам придется отследить вручную, чтобы увидеть, кто отправил это значение null.

0