Должен ли метод игнорировать незаконный ввод или создавать исключение?

Question

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

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

Я не уверен, какой путь лучше. Поэтому я спрашиваю вас: что вы думаете по этому вопросу?

Answer 1

Определенно исключение. Исключения раздражают с целью заставить вас что-то делать о них.

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

Answer 2

Это зависит от приложения, которое вы разрабатываете.

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

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

Вы должны попытаться подумать о возможных последствиях обработки ошибок в конкретном методе, который вы пишете, и о том, как ваша обработка ошибок повлияет на общее приложение.

Answer 3

Предполагая, что это общедоступный метод, каков контракт между методом и теми, кто вызывает этот метод?

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

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

В конце концов, это действительно зависит от того, что делает этот метод, и от каких ожиданий от метода.

Вы можете заменить класс для метода и иметь те же параметры.

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

Приветствия,

-R

Answer 4

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

Answer 5

Fail Fast: Никогда не игнорируйте неправильный ввод. Вы можете скрыть проблему и сделать их очень трудными для поиска.

Некоторые толчок очень далеко от Design by Contract (DBC).

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