Обрабатывать или не обрабатывать нулевые параметры с исключениями

Question

Я помню, как читал руководство по обработке исключений, что проверка на нулевые параметры не рекомендуется.Обоснованием этого было то, что если вы оставили код как есть, возникнет исключение (NullReferenceExcpetion), когда вы попытаетесь использовать параметр.Альтернативой является явная проверка на нулевое значение и создание исключения ArgumentNullException.

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

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

Обычно я проверяю нулевые параметры только на не приватных методах, но оставляю закрытые методы для создания исключения NullReferenceException.

Кто-нибудь знает, существует ли какая-либо определенная / де-факто лучшая методическая рекомендация по этому вопросу, такЯ могу обновить свой подход, если это необходимо?

Answer 1

Это дает тот же эффект, но вы правы дополнительные строки кода

Нет, это не так. Рассмотрим:

public void TransferMoney(Account from, Account to, decimal amount)
{
    from.Debit(amount);
    to.Credit(amount);
}

против

public void TransferMoney(Account from, Account to, decimal amount)
{
    // Ideally do them separately
    if (from == null || to == null)
    {
        throw new ArgumentNullException();
    }

    from.Debit(amount);
    to.Credit(amount);
}

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

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

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

Обычно я проверяю нулевые параметры только на не приватных методах, но оставляю приватные методы для выдачи исключения NullReferenceException.

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

Answer 2

С проверкой вы можете передать имя параметра в исключении, что упрощает отладку.

if (x == null) throw new ArgumentNullException(nameof(x));