Это хорошая практика, чтобы бросить исключение раньше, чем позже?

Question

Сегодня я столкнулся со следующей ситуацией: ("псевдокод")

class MyClass {

    public void workOnArray(Object[] data) {
        for (Object item : data) {
            workOnItem(item);
        }
    }

    public void workOnItem(Object item) {
        if (item == null) throw new NullPointerException();
    }
}

Теперь, если вызывающий вызов вызывает workOnArray с массивом, содержащим null элементов, вызывающий получит NullPointerExceptionиз-за workOnItem.

Но я мог бы добавить дополнительную проверку в workOnArray, другими словами, проблема может быть обнаружена раньше.

(Обратите вниманиечто это тривиальный пример, в реальном приложении это может быть гораздо менее очевидно).

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

С другой стороны, я бы спросила себя: «Если я это сделаю, разве мне не нужно проверять каждый параметр, передаваемый в основной API моего языка программирования, ивыбросить точно такие же исключения? "

Есть ли какое-то эмпирическое правило, когда выкидывать исключения рано, а когда просто позволить вызываемому объекту бросить его?

Answer 1

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

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

Answer 2

В этом примере метод workOnItem заботится о том, является ли элемент пустым.Метод workOnArray не заботится о том, являются ли элементы нулевыми, и поэтому IMO не должен проверять, являются ли какие-либо элементы нулевыми.Метод workOnItem действительно заботится и поэтому должен выполнить проверку.

Я бы также рассмотрел возможность создания более подходящего типа исключения из workOnItem.NullPointerException (или в C #, NullReferenceException) часто указывает на некоторый неожиданный недостаток в работе метода.В C # я был бы более склонен выдавать исключение ArgumentNullException, содержащее имя нулевого параметра.Это более ясно указывает на то, что workOnItem не может продолжаться, поскольку он не может обработать получение нулевого аргумента.