Помогает ли в чём-нибудь? Я думал, что в случае вызова Optional::get() c отсутствующей ссылкой (null) выбрасывается проверямое исключение, что заставляет оборачивать каждый вызов get() в try/catch, что в свою очередь гарантирует, что любое обращение к объекту будет проверять случай отсутствия ссылки. Но там RuntimeException, поэтому ничего не мешает вызывающему get() забыть сделать проверку и вместо NullPointerException получить NoSuchElementException.

Единственное преимущество, которое я нашёл, это более короткий синтаксис в случае, когда надо нулевую ссылку заменить значением по-умолчанию. В этом случае пишется что-то вроде Optional.ofNullable(maybeNullable).orElse(nonNullable).

M>В этом случае пишется что-то вроде Optional.ofNullable(maybeNullable).orElse(nonNullable).

А ещё между ofNullable и orElse много чего можно вставить

Здравствуйте, mbait, Вы писали:

M>Помогает ли в чём-нибудь? Я думал, что в случае вызова Optional::get() c отсутствующей ссылкой (null) выбрасывается проверямое исключение, что заставляет оборачивать каждый вызов get() в try/catch, что в свою очередь гарантирует, что любое обращение к объекту будет проверять случай отсутствия ссылки. Но там RuntimeException, поэтому ничего не мешает вызывающему get() забыть сделать проверку и вместо NullPointerException получить NoSuchElementException.

M>Единственное преимущество, которое я нашёл, это более короткий синтаксис в случае, когда надо нулевую ссылку заменить значением по-умолчанию. В этом случае пишется что-то вроде Optional.ofNullable(maybeNullable).orElse(nonNullable).

Ну например самим фактом декларации типа переменной / возвращаемого значения как Optional<T>, явно на уровне типа говори о том что значения может не быть.

interface UserDao<Id> {
    // все очевидно пользователь не ждет тут NoSuchUserException extends RuntimeException
    Optional<User> findById(Id id) 

    // а тут вот черт его знает вернет она null или кинет исключение
    User get(Id id) 
}

Ну и всякая там в стримах обработка понятно, безопасные конвертации, проверки условий.

Optional<User> user = userDao.findById(...);
return user.stream()
         .filter(u -> !u.isBlocked())
         .map(ActiveUserDTO::new)
         .elseThrow(() -> new UserBlockedException());

В java9 вроде как Optional implements Iterable что позволяет например использовать

Optional<User> maybeUser = userDao.findById(...);
for(User u : maybeUser) {
    // тут User точно есть
}
// вместо традиционного 
if(maybeUser.isPresent()) { 
   // process User
} else {
   // doRegret
}

Но то такое, для любителей странного

В догонку...чего не стоит делать с Optional, не стоит принимать его на вход

interface UserValidator {
    boolean isValid(Optional<User> maybeUer)
}

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

Ну и в сочетании в аннотациям например JSR-305 вполне можно говорить о каком-то null-safety.

Здравствуйте, frёёm, Вы писали:

ёё>В java9 вроде как Optional implements Iterable
Проверка этого факта заняла бы меньше времени, чем написание последующего текста.
https://docs.oracle.com/javase/9/docs/api/java/util/Optional.html

Правильный ответ:
https://docs.oracle.com/javase/9/docs/api/java/util/Optional.html#stream--

Здравствуйте, mbait, Вы писали:

M>поэтому ничего не мешает вызывающему get() забыть сделать проверку и вместо NullPointerException получить NoSuchElementException.
Intellij IDEA, зная о семантике Optional, ловит такие ситуации и подсвечивает проблемные места. Ну и NoSuchElement уже интереснее и, часто, проще расследовать, чем NPE.