Подтвердить что ты не робот

Какое исключение бросить?

У меня есть функция, которая вычисляет среднее из списка, переданного в качестве аргумента. Я хотел бы знать, какое из исключений Java я должен использовать, когда пытаюсь вычислить среднее из списка размером 0.

public double mean (MyLinkedList<? extends Number> list)
{
    if (list.isEmpty())
        throw new ????????; //If I am not mistaken Java has some defined exception for this case

    //code goes here
}

Спасибо.

4b9b3361

Ответ 1

Вы можете выбросить new IllegalArgumentException().

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

Просто не забудьте передать ясное сообщение в качестве первого аргумента. Это действительно поможет вам понять, что произошло.

Например, "Нельзя использовать среднее значение для пустого списка".

Ответ 2

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

К сожалению, нет лучшей отраслевой практики в решении этих проблем, как показано в ответе StackOverflow:

В Java, когда я должен создать проверенное исключение и когда это должно быть исключение во время выполнения?

Тем не менее, есть несколько ключевых соображений:

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

  • Согласованность с другими методами в классе/пакете

  • Соответствие действующему стандарту кодирования (если есть)

Мое мнение:

  • Возврат Double.NAN или 0 Если вызов метода с 0-размерным списком является разумным/ожидаемым/нормальным, я бы подумал о возврате Double.NAN или 0, если 0 подходит для вашего проблемного домена.

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

  • Выбросить настраиваемое исключение проверки. Если этот метод является частью пакета статистики или библиотеки, где несколько функций статистики должны иметь дело с возможным пустым набором данных, я думаю, что это исключение, которое является частью проблемной области. Я бы создал пользовательское (возможно, проверенное) исключение (например, EmptyDataSetException), чтобы быть частью класса/пакета/библиотеки и использовать его во всех применимых методах. Предоставление проверенных исключений помогает напоминать клиенту о том, как обрабатывать условие.

Ответ 3

Вам следует создать новый класс, который расширяет Exception и предоставляет детали, специфичные для вашей ошибки. Например, вы можете создать класс с именем EmptyListException, содержащий сведения о вашей ошибке. Это может быть очень простой класс исключений, который не принимает аргументов конструктора, но может вызвать super("Cannot generate mean for an empty list");, чтобы предоставить настраиваемое сообщение для трассировки стека.

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

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

Ответ 4

IllegalArgumentException

Ответ 5

Как насчет исключения NoSuchElementException. Хотя IllegalArgumentException может быть лучше.

Ответ 6

Как об исключении ArithmeticException - так же, как и время выполнения.

Ответ 7

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

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

Ответ 8

Я не уверен, что вы вообще должны исключать исключение; среднее значение "ничего" - "ничего" или 0, если хотите. Если набор пуст, вы должны просто вернуть 0.

Если вы действительно ДОЛЖНЫ выбросить исключение, то вы можете выбрать IllegalStateException или IllegalArgumentException.