Где ловить и обрабатывать нулевые аргументы?

Question

Когда я пишу код, я часто задаю себе один и тот же вопрос:

Нужно ли проверять, что все аргументы не равны нулю?Итак, в каждом методе у меня будет что-то вроде этого:

if (arg1 == null) 
{
    throw FooException("...");
}

if (arg2 == null) 
{
    throw FooException("...");
}

Если нет, то в каком случае предпочтительнее?

Каковы лучшие практики?

Answer 1

Как всегда, это зависит.

Если вы пишете API для использования другими командами / организациями, такое защитное программирование с проверкой предварительных условий для общедоступных функций действительно может помочь вашим пользователям;при использовании внешней библиотеки осмысленное сообщение об ошибке типа «аргумент, передаваемый в foo () не должен быть нулевым», намного лучше, чем NullPointerException, генерируемое из некоторого внутреннего класса.

За пределами API, хотя я думаю, что такие проверкислишком много загромождать код.Брошенные исключения NullPointerException обычно довольно легко отследить с помощью отладчика.На языках, которые их поддерживают, вы можете рассмотреть возможность использования утверждений - их синтаксис обычно менее громоздок, и вы можете отключить их на производстве, чтобы проверки не снижали производительность.

Answer 2

К сожалению, да.Вы должны проверить все аргументы.Теперь, в идеале, если вы пишете код с хорошими практиками проектирования, одна функция должна содержать не более 4-5 аргументов, самое большее

Сказав это, следует всегда проверять наличие нулевых значений в записи функции и генерировать соответствующее исключение или IllegalArgumentException (моя любимая).

Кроме того, никогда не следует передавать NULL в функцию и никогда не возвращать NULL.Звучит просто, но это сэкономит много кода и ошибок.Взгляните также на NULL Design Pattern .

Answer 3

Я чувствую, что в основном это из-за здравого смысла, и немного из-за личных предпочтений.

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

Если это внутренний код, то есть два других варианта, о которых следует подумать: использовать утверждения или не беспокоиться о проверке и полагаться на отладку. Как правило, я добавлю утверждения, если это будет код, который, как я ожидаю, будут вызывать другие разработчики, или если условие достаточно тонкое, чтобы отладка могла вызывать трудности. В противном случае я просто позволю этому потерпеть неудачу.

Иногда эту проблему можно избежать, используя шаблон Null Object . Если бы это был публичный API, я все равно был бы склонен включить проверки.

Answer 4

В идеале вы должны всегда проверять любые аргументы, прежде чем выполнять какое-либо действие, которое может изменить любое состояние или данные, связанные с указанными аргументами. Лучше потерпеть неудачу рано и управляемым способом (создавая исключение), чем в итоге получить противоречивое состояние / данные, которые затем также должны быть разрешены.

Ваши методы ожидают, что определенные данные будут там, есть некоторые случаи, когда можно с уверенностью предположить, что они действительно есть (скажем, внутри частного метода, который вызывается из других методов, которые проверяют ввод). Однако в целом я бы порекомендовал проверять аргументы, когда они:

• Поставляется пользователем.
• Поставляется как часть API.
• Передается между модулями системы.

Возможно, стоит взглянуть на этот предыдущий вопрос StackOverflow.

Answer 5

Так как вы в любом случае генерируете исключение, не проверка их может привести к нулевому исключению или к чему-то подобномуЯ не совсем уверен, каковы лучшие практики сам.

Answer 6

Зависит, если вы хотите разные исключения, я думаю, вам придется делать это во всех случаях, когда вы можете получить нулевое значение. Другой способ будет для пользователя DATATYP.TryParse (). Посмотри на это.

Надеюсь, это поможет.