Должен ли сервис генерировать исключение или возвращаться, если для удаления не задано

У меня есть кусок кода, который может быть представлен как:

public class ItemService {

    public void DeleteItems(IEnumerable<Item> items)
    {
        // Save us from possible NullReferenceException below.
        if(items == null)
            return;

        foreach(var item in items)
        {
            // For the purpose of this example, lets say I have to iterate over them.
            // Go to database and delete them.
        }
    }
}

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

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

Это два разных вопроса.

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

Должны ли вы принять пустую коллекцию? На мой взгляд: ДА, абсолютно. Гораздо больше усилий ограничить все вызывающие объекты непустыми коллекциями, чем сделать математически правильную вещь - даже если это удивляет некоторых разработчиков, которые сомневаются в концепции нуля.

Нулевое значение

Как уже сказал @KilianFoth, придерживайтесь своей общей политики. Если это должно рассматриваться nullкак «сокращение» для пустого списка, сделайте это так.

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

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

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

Пустой список

Для DeleteItems()метода передача пустого списка фактически означает ничего не делать. Я бы позволил это в качестве аргумента, не выбрасывая исключение, а просто быстро возвращаясь.

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

Брось исключение и обработай нули в вызывающем коде.

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

Кроме того, посмотрите на остальную часть вашего кода. Если это обычный шаблон в вашем проекте, оставайтесь последовательными.

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

Вы можете применить этот мыслительный процесс к этой ситуации. Учитывая, что это открытый класс с открытым методом, у вас есть открытый API, и в теории нет контроля над тем, что ему передается.

Ваш код не имеет контекста о том, что его вызывает (как он должен делать), и вы ничего не можете разумно сделать с нулевым значением. Это, безусловно, будет кандидатом на ArgumentNullException.

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

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

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

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

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

Я бы, вероятно null, допустил ошибку, допустив значения, определив и задокументировав их семантику (т. Е. В null = empty arrayданном случае), и не выбросил бы исключение, если 99% вашего другого аналогичного кода (кода стиля «библиотека») не делают это иначе. 'круглый.