Optional недоФП

как ты узнаешь что оно возвращает null или кидает исключение?

вообще есть throws при этом нет запрета указывать там NPE (это помимо документации)

С этим закончили, ещё причины есть?

вообще есть throws при этом нет запрета указывать там NPE (это помимо документации)

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

С этим закончили, ещё причины есть?

Причина одна и ради неё новые языки создают, у которых эти Optional в синтаксисе (Swift, Kotlin например). Java синтаксис поменять вряд ли сможет, но в привычной Java многословной манере Optional проблему таки решает.

Конечно Optional повышает читаемость, NPE ошибка в момент исполнения, а чтоб знать вернет или нет метод null и нужна ли проверка, нужно смотреть в javadoc. Либо однозначно вернуть Optinal. Но то как TC использовал Optinal это очень плохо, escape анализ конечно отработает, но код плох, он не понятен, не интуетивен, ТС уже сказал про Optional «ну это грех не знать-то...», как бы в команде такие и более высокопарные выражения создают токсичную обстановку, а это может убить продуктивность команды.

писать там можно что угодно (если речь не про checked исключения).

Также как и опшионал можно сделать, но кидать исключение. Незачот.

Причина одна

Так какая?

а чтоб знать вернет или нет метод null и нужна ли проверка, нужно смотреть в javadoc

вас не смущает, что вы документацию в рантайм, по сути, суёте? при том явно это декларируя, мол вот этот _лишний_ объект (и вызов метода), потому, что _мне_ лень доку прочитать (или сорцы глянуть).

вас не смущает, что вы документацию в рантайм, по сути, суёте?

Почему в рантайм? В компайлтайм.

Optional - в рантайме не существует?

Optional - в рантайме не существует?

В приличных языках - нет. Думаю, и в Яве тоже, т.к. null может использоваться как признак отсутствия значения.

Думаю, и в Яве тоже,

всё понятно

А конкретнее? Может, у тебя ссылки есть на реализацию Optional-ов JIT-компилятором? Или ты посмотрел на Java-исходник и всё понял? %)

вас не смущает, что вы документацию в рантайм, по сути, суёте? при том явно это декларируя, мол вот этот _лишний_ объект (и вызов метода), потому, что _мне_ лень доку прочитать (или сорцы глянуть).

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

(или сорцы глянуть).

Утопия. Чтение и анализ кода меленее чтения декорации. И мы говорим про java а не про числодоробилку на си, тут оптимизации ухудшающие читаемость не приняты.

Доку часто

Точно также можно пообещать Optional а вернуть null, пожлст без демагогии.

Давайте так: «я сознательно сую документацию в рантайм» — вы это скажете, и у меня вопросов не будет. А так это какие-то отговорки про ленивых кодеров.

Точно также можно пообещать Optional а вернуть null, пожлст без демагогии.
пожлст без демагогии.

Лол :)

Всё?

Давайте так: «я сознательно сую документацию в рантайм» —

Да. Лучшая документация это код.

Да. Лучшая документация это код.

Не смог. Всё равно нужно оправдать себя, подпереться какой-то мудрой фразой 8)

TC использовал Optinal это очень плохо
ТС уже сказал про Optional «ну это грех не знать-то...»
убить продуктивность команды.

ну а потом даже такой код будет затруднения вызывать

private Duration readKeyLifetime() {
    return jdbcTemplate.query(
        "select extract(epoch from key_lifetime())::bigint",
        (rs, rn) -> Duration.ofSeconds(rs.getLong(1))
    ).stream()
        .findFirst()
        .orElseThrow(() -> new CriticalSystemError("key_lifetime() returns no rows"));
}

Всё?

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

Разве это плохо? В конечном итоге don't be evil :)

Я уже сказал про доку, что на нее статических анализаторов не навесишь

Омг, для любителей анализировать есть аннотации. У меня складывается впечатление, что людям дали этот опшионал, а они как «мартышка и очки», пытаются его водрузить везде и всюду (особенно ТС), не задумываясь, что всё это давно уже есть и даже лучше. И нужен этот опшионал для хайпа (у вас нет опшионала? ява гогно, везде есть!) и прикостыливания кривых стримов, которые какраз-таки без него печальны.

скажут, подавай нам орм, мы не понимаем...

Нет, этот код читаем. Но если бы код не касался I/O то меня бы беспокоила его производительность, но т.к. все упрется в базу, норм.

Аннотации годятся, но лично я отдам предпочтение Optional.

Optional.ofNullable(store.get(keyId)).orElseThrow(() -> {} );

А вот код из оригинального примера читается так же хорошо как вот это:

if (!isNotEmpty) { } 

мы видимо поразному читаем просто...

String тутПолюбомуНеНул = Optional.ofNullable(кривойИнтерфейс.гет)
.map(...processValue...)
.orElseThrow(() -> new wtf());

vs

String чтото = кривойИнтерфейс.гет;
if (чтото == null) {
   // bad value
   throw new wtf();
}
String тутПолюбомуНеНул = processValue(чтото);

а это не скомпилится даже

Optional.ofNullable(store.get(keyId)).orElseThrow(() -> {} );

Я просто сократил. Начинаю уже привыкать к Optional.ofNullable().orElseThrow и теперь он кажется абсолютно понятным, но думаю этот навык быстро потеряется, есть ведь такой эффект, возвращается к коду через пол года и не понимаешь кто это написал.

Но между двумя версиями есть разница, думаю в версии с map мы будем придерживается конвенции исключающей side effect а во втором случае мы себя не ограничиваем правилами из функционального мира. По-моему было бы логично? Нет?

про сайд эффект логично да.

момент еще такой, как обычно пишут джуны:

String чтото = кривойИнтерфейс.гет;
if (чтото != null) {
    // String тутПолюбомуНеНул = processValue(чтото);
    // добавлено через полгода
    String чтото2 = кривойИнтерфейс2.гет;
    if (чтото2 != null) {
        String тутПолюбомуНеНул = processValue2(чтото, чтото2);
        return тутПолюбомуНеНул; 
    } else {
       if (...) // etc...
    }
}
// в лучшем случае, обычно return null;
throw new wtf();

(это помимо документации)

О, еще один любитель документации...

Точно также можно пообещать Optional а вернуть null, пожлст без >демагогии.
пожлст без демагогии.

Лол ) Тот, кто возвращает null на Optional вредитель или проф не пригоден.

лично я отдам предпочтение Optional.

Я это уже понял 8)

А ведь когда-то в Java была новизна, своя изюминка. Она предлагала новые решения. А теперь по этой теме на ЛОР хорошо видно, как Java с пребольшим трудом поспевает за новыми веяниями времени. Да, ни что не вечно!