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

Если конструктор экземпляра класса содержит параметры ссылочного типа, то как лучше в общем случае поступать:
1. Организовать проверку аргументов на null прямо в конструкторе (например, если речь о массиве, то можно провести проверку на null и если null, то создать массив-заглушку нулевой длины и т.п., либо как-то по другому обработать эту ситуацию)
2. Организовывать проверка на null перед вызовом конструктора
3. Не проверять на null вообще - если выдаст исключение, то это будет говорить о неверной логике программы

0

titan4ik, Как по мне, то многое зависит от конкретной реализации. Но если постараться как-то "обобщить", то я думаю так:

Сообщение от titan4ik 1. Организовать проверку аргументов на null прямо в конструкторе (например, если речь о массиве, то можно провести проверку на null и если null, то создать массив-заглушку нулевой длины и т.п., либо как-то по другому обработать эту ситуацию)

В принципе, если говорить о List например, то лучше просто добавить в него дефолтное значение, которое будет создавать пустой List (то есть List без инициализации в консрукторе всеравно не будет null). Также в конструкторе можно проверять и давать переменным дефолтные значения, если значение null.

Но здесь главное с умом. Потому что если в List мы знаем, что там будет именно такой List, а вопрос только - пустой или уже чем-то заполнен сразу, то с классами, которые вы создаете, все не так однозначно и часто для переменных удобно использовать null, чтобы потом просто проверять: если не null - значение переданы, если null - то по тем или иным причинам значения нет.

Сообщение от titan4ik 2. Организовывать проверка на null перед вызовом конструктора

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

Сообщение от titan4ik 3. Не проверять на null вообще - если выдаст исключение, то это будет говорить о неверной логике программы

Это тоже возможно, но зависит, опять же, от ситуации. Например, если вы принимаете в юзера аргументом List, но ваш код может работать и с пустым List-ом, то будет не слишком правильным просто оставлять все так и выдавать ошибку, ведь мы это могли очень легко учесть и избежать. Но если пользователь должен передать класс Students (в котором должны быть разные ученики, их количество и т.д.) то будет вполне целесообразно выдать сразу ошибку о null, причем, в идеальном варианте, через try / catch с понятным текстом.

1

Sacred6661,
иными словами - нужно в каждом конкретном случае руководствоваться здравым смыслом. Никаких общих требований и/или рекомендаций нет.

1

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

0

titan4ik, Если null - допустимое значение (лучше так не делать) - обрабатывать в зависимости заложенной логики, иначе - бросать эксепшн.
Всяческие заглушки, null-object паттерн, например - это проблемы вызывающей стороны. Сам класс не может, и не обязан знать, передали ли ему null по ошибке, или это так и задумывалось.
В, целом, жадничать на ArgumentNullException не нужно. Жмотство в отношении этой штуки приводит к веселым танцам с бубном отладчиком и анализу нескольких килограммов логов в 3 часа ночи в попытках найти корень всех зол.

1

Сообщение от aenye В, целом, жадничать на ArgumentNullException не нужно.

Вы имеете ввиду использовать в конструкторе try/catch ?

0

titan4ik, неа.
Вот самый банальный пример:

1

aenye, спасибо, понятно.
А если дело касается не полей, а свойств, то это лучше делать в сеттере свойства, а не в конструкторе?
У меня интуитивное представление, что конструктор нужно поменьше загружать разными функциями.

0

Сообщение от titan4ik А если дело касается не полей, а свойств, то это лучше делать в сеттере свойства

В целом да. Частенько инициализация пропертей через конструктор происходит, а значение через метод меняется. Если при этом сделать валидацию не в сеттере - то в конструкторе условие поменяете, а в методе - забудете. И будут ошибки из-за неоднозначности.
Но бывают ситуации, когда такую реализацию не получается использовать.

Добавлено через 15 минут

Сообщение от titan4ik У меня интуитивное представление, что конструктор нужно поменьше загружать разными функциями.

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

2

aenye, спасибо!

0