Необязательный может использоваться в качестве альтернативы для ловли ConversionException

Question

Как выполнить рефакторинг следующего кода файла свойств чтения, чтобы он возвращал значения типа int, double или String в зависимости от значения для чтения?

    public static <T> T readFromConfig(String keyName) {
    PropertiesConfiguration config = new PropertiesConfiguration();
    String propertiesFilePath = "src/main/resources/application.properties";
    try {
        config.load(propertiesFilePath);
        try {
            Integer value = config.getInt(keyName);
            return (T) value;
        } catch (ConversionException notInteger) {
            try {
                Double value = config.getDouble(keyName);
                return (T) value;
            } catch (ConversionException notDouble) {
                return (T) config.getString(keyName);
            }
        }
    } catch (ConfigurationException e) {
        logger.warn("Could not parse " + propertiesFilePath);
        return (T) "";
    }
}

Answer 1

Я могу предложить вам следующее: это явное нарушение принципа единой ответственности (SRP), поскольку он пытается преобразовать в три различных типа, которых следует избегать для более чистого кода:

public static Optional<Object> readFromConfig(String keyName) {
    PropertiesConfiguration config = new PropertiesConfiguration();
    String propertiesFilePath = "src/main/resources/opf.properties";
    try {
        config.load(propertiesFilePath);

        return Stream.<Supplier<Optional>>of(
                () -> Optional.of(config.getInt(keyName)),
                () -> Optional.of(config.getDouble(keyName)),
                () -> Optional.of(config.getString(keyName)))
                .map(Supplier::get)
                .filter(Optional::isPresent)
                .map(Optional::get)
                .findFirst();

    } catch (Exception e) {
        return Optional.empty();
    }
}

Answer 2

Как полагал сам автор: Optional<> здесь не вариант, потому что, как показывает другой ответ: это приведет к возвращению Optional<Object>, что дает даже меньше информации о типе.

Но, честно говоря, с точки зрения чистого кода, даже идея

public static <T> T readFromConfig(String keyName) {

является своего рода ущербным . Что покупает этот метод? Ничего . Потому что звонящий говорит: я ожидаю, что Integer вернется, но вы отбрасываете Double или даже String. Видите ли, компилятору сообщают, что «метод должен возвращать Integer или Double, ...», а затем он видит: «да, возможно». Но это полностью отделено от того, что происходит во время выполнения.

Если вы идете:

Integer intVal = readFromConfig("keyPointingToDoubleValue");

компилятор не будет жаловаться. Потому что он видит: вы хотите целое число; и эй, метод может вернуть целое число.

во время выполнения? Когда значение извлекается и не является целым числом, возвращается значение Double или String. Понятия не имею, что здесь произойдет (исключение приведения класса или, возможно, какое-то нарушение стека). Но он должен не работать во время выполнения.

Итак, решение real выглядит следующим образом:

Либо у вас есть несколько методов, таких как:

public static Integer readIntegerFromConfig(String keyName) throws SomeException ...
public static Integer readIntegerFromConfig(String keyName, Integer Default) throws SomeException ...

Или, может быть:

public static Object readFromConfig(String keyName) {

или

public static <T> T readFromConfig(String keyName, T default)

Другими словами: вам нужен API, который позволяет пользователям действительно говорить, что они хотят, и всегда давать им то, что они хотят. Или вы полностью избегаете различных типов на этом уровне и возвращаете Strings, и клиентский код выполняет преобразования.

Ваш нынешний подход, как сказано: ничего не покупает, за счет вводящего в заблуждение сложного API.

Answer 3

Итак, это конец дискуссии. Ответ на вопрос «Может ли Optional использоваться в качестве альтернативы для отлова ConversionException?» is NO