Что лучше всего обрабатывать непринятые аргументы метода в Java?

Question

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

То, как я это делаю:

1. ВИнтерфейс, я документирую внутри метода javadoc, что аргументы a, b и c не могут быть нулевыми.
2. Внутри метода я сначала проверяю нулевые значения, и если какие-либо из a, b или c равны нулю, тогда я выкидываюIllegalArgumentException.

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

Есть ли способ применить это во время компиляции?Я сомневаюсь в этом, но какой самый безопасный и защищенный разработчиком способ сделать это?

Answer 1

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

Если вы не помоете, добавив зависимость в одну из платформ валидации, вы можетеиспользуйте JSR 303 @ NotNull или аналогичные инструменты, такие как Предварительные условия .

С JSR 303 вы можете сделать достаточно:

@NotNull
@Size(min = 2, max = 14)
@UpperCase
private String licensePlate;

или

@NotNull
@NotEmpty
public String foo(@NotNull @Pattern(regexp="[0-9]") String param) {
   ...
}

Более подробные примеры можно найти в Начало работы с проверкой bean-компонента JSR 303 .

Answer 2

Вы можете использовать jsr305 со статическими инструментами проверки кода, такими как findbugs, чтобы проверить его перед коммитом / выпуском.

Answer 3

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

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