Как я могу проверить недопустимый тип перечисления в случае переключателя?

Я нашел лучшее решение, удалив регистр по умолчанию из оператора переключателя. Если вы опустите регистр по умолчанию и переключатель не охватывает все возможные значения перечисления, компилятор выдаст ошибку: «Выражение Switch должно охватывать все возможные значения Java(1073743533)». Такой подход гарантирует, что если в будущем будет добавлено новое значение перечисления, код не будет компилироваться до тех пор, пока новое значение не будет явно обработано, что делает его более надежным и удобным в обслуживании решением.

Вот как я это сделал:

Оригинальный метод:

public ResponsePaginatedDto execute(DeviceType type) {
    return switch (type) {
        case APP -> handleApp();
        case WEB -> handleWeb();
        case DESKTOP -> handleDesktop();
        default -> throw new UnsupportedOperationException();
    };
}

Модифицированный метод:

public ResponsePaginatedDto execute(DeviceType type) {
    return switch (type) {
        case APP -> handleApp();
        case WEB -> handleWeb();
        case DESKTOP -> handleDesktop();
    };
}

Этот конкретный пример - исправление

Блок switch здесь используется как выражение. Это означает, что вы просто полностью удаляете блок default:

• Ваш код скомпилируется нормально.
• Когда вы добавляете новое значение в это перечисление, вы получаете красную волнистую подчеркивание в этом блоке переключателей, что значительно лучше, чем «все компилируется и работает, казалось бы, нормально, пока код не взорвется с UnsupportedOperationException без сообщения».
• Если каким-то образом вам удастся запустить этот код, добавив при этом перечисление (что требует, чтобы вы скомпилировали исходный файл с этим ключом в момент времени X и перекомпилировали исходный файл, содержащий перечисление, в момент времени Y, где X предшествует Y, и в X перечисление имело только 3 значения, которые оно имеет сейчас, тогда как в Y вы добавили значение - маловероятный/невозможный сценарий, если вы очистите сборку перед развертыванием, что обычно и нужно), вы... получите исключение. Не UnsupportedOperationException, а java.lang.MatchException, но тем не менее исключение.

Это решит все ваши проблемы, если вы готовы принять MatchException вместо UnsupportedOperationException. Это даже намного лучше: теперь вы можете получить 100%-ное покрытие тестами и получать предупреждения во время компиляции, если вам не удается охватить перечисление, вместо туманной ситуации «надеюсь, что когда-нибудь произойдет какая-то ошибка», и меньше печатать и читать Код переключателя больше не предполагает ошибочного предположения, что 3 значения перечисления, для которых вы написали case, не охватывают все это и что есть 4-е или 5-е. Ведь если не было, зачем писать default?

Этот конкретный пример — плохой код

100% тестовое покрытие — это глупая загвоздка. Это не значит, что ваш код великолепен. Например, здесь вы написали довольно плохой код. Если когда-либо происходит невозможное и выдается UnsupportedOperationException, то смысл сообщения об ошибке, являющегося частью исключения, заключается в передаче полезной информации, имеющей отношение к данному случаю. «Параметры, которые привели к ошибке», более или менее. Здесь, конечно, вы передаете ценность! Так и должно быть throw new UnsupportedOperationException(type.name()) - то что нет - это баг, прям. Однако это ошибка, которую вы не можете проверить. Видеть? Сам ваш фрагмент доказывает, что стремление к 100%-ному покрытию тестами — это странная вещь. Это не дает вам какой-то хваленой награды «ошибки вообще невозможны», и этот последний 1% требует, чтобы вы полностью удалили защитный/резервный код, потому что вы не можете сделать это, не разрушая свою кодовую базу и фактически увеличивая шансы. этой проблемы, добавляя способы создания невозможного состояния (хотя бы только для того, чтобы ваши тесты могли охватить невозможное состояние). ¹

Для всех таких сценариев не существует хорошего решения!

Здесь мы смогли «исправить» проблему и предоставить вам код, который был бы лучше, чем у вас, а также получить другие приятные преимущества, а также обеспечить 100% тестовое покрытие.

Но не всегда все так хорошо: иногда резервная/защитная строка кода весьма полезна в качестве защиты, но тогда вы сталкиваетесь с дилеммой. Или:

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

• На самом деле вы добавляете код и значительно усложняете его отслеживание, намеренно создавая опоры исключительно для целей ваших тестовых случаев: вы позволяете создать эту непостижимую ситуацию только для того, чтобы вы могли ее протестировать. Звучит здорово (дааа, 100% тестовое покрытие, балл!), но не так быстро. Этот код почти наверняка намного хуже, чем код без всего этого странного круфта, который вместо этого набирает 99%. Видя в коде способ создания целого ряда новых состояний, вам становится сложнее рассуждать об этом, и, что также важно, автоматическим инструментам это сделать становится невозможным. Тот факт, что способы создания этих новых состояний, которые трудно даже объяснить (поскольку они не моделируют ничего из реальной жизни - вы добавили их исключительно для проверки защитных/запасных вариантов), не помогает. Это настоящий «доктор, мне больно, когда я бью молотком по лицу». Ответ: тогда перестаньте это делать.

100% покрытие кода — это инструмент. Если использование инструмента требует, чтобы ваш код стал плохим и его было труднее рассуждать, правильный образ действий — прийти к выводу, что инструмент плох в том сценарии, в котором вы оказались. Не прогибаться назад и умирать на этом холме.

Третий способ — просто удалить все резервные варианты. Любой код, который пытается сработать в сценарии, который вы не можете понять, вместо этого может быть удален. Однако это очень плохая идея. Не только потому, что предполагается, что вы всеведущи. А еще потому, что резервные варианты защищают от неправильной интерпретации того, как написанный код будет использоваться будущими программистами.

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

if (rectangle.getWidth() < 0) throw new IllegalArgumentException("Negative width rectangles not allowed");

Это хорошая вещь. Даже если сегодня невозможно создать прямоугольники с отрицательной шириной, возможно, завтра какая-нибудь предприимчивая душа добавит это в систему и не учтет, что код, в котором это есть if, необходимо обновить, чтобы справиться с этим. Прежде чем продолжить: «Отрицательная ширина? Что за чушь, такая нелепая вещь никогда не может случиться» — долгое время математики думали так же, пытаясь извлечь квадратный корень из отрицательного числа, пока кто-то не сказал: «Давайте просто… определим некоторую константу как значение». для sqrt минус 1 и посмотрим, что произойдет.

Вы не знаете того, чего не знаете, и не можете объяснить необъяснимое.

Следовательно, защитные/запасные линии — необходимая вещь в кодировании, они могут быть хорошей идеей. И они непроверяемы.

Помните свое лицо и молот?

Перестаньте его размахивать.

[1] К сожалению, MatchException также не печатает непокрытое значение. Это плохо, и OpenJDK должен это исправить. Однако это может дать вам возможность распечатать непокрытое значение в более поздней версии. Это не просто несбыточная мечта: это случилось с NullPointerException: на современных JVM, если NPE вызван разыменованием (вместо new NullPointerException(...)), сообщение сгенерированного NPE будет включать текстовое представление выражения, которое было null если это достаточно просто сделать. Это означает, что если бы вы только что оставили это значение на return person.getName(), вы бы получили NPE с текстом person, тогда как если бы вы явно написали if (person == null) throw new NullPointerException();, вы этого не получите. «Ленивый» программист побеждает.