'Optional.get()' without 'isPresent()' check

Question

I have the following search code in Java:

return getTableViewController().getMe().getColumns().stream()
    .filter($ -> Database.equalsColumnName($.getId(), columnId))
    .findFirst()
    .get();

I was wishing to find column by name and return first one found.

I understand there is a case when nothing found and it should be processed, but how?

Is this what it wants by this swearing:

'Optional.get()' without 'isPresent()' check

?

How to fix? I wish to return null if nothing found.

UPDATE

Okay, okay, I just didn't realize, that findFirst() returns Optional.

Solution 1

Replace get() with orElse(null).

Solution 2

...findFirst().orElse(null);

Returns the value if present, otherwise returns null. The documentation says that the passed parameter may be null (what is forbidden for orElseGet and orElseThrow).

Solution 3

my solution was to check it this way

if(item.isPresent()){
  item.get().setId("1q2w3e4r5t6y")
}

Comments

[Dims]

Why? :) Why orElse starts with "or"?

[Andy Turner]

Because that's the method name. And else is a keyword.

[puhlen]

@Dims its just a short form of getOrElse, just leaving out the get. With optional you should normally use orElse instead of get because get will throw an exception if the value is null.

[bcsb1001]

@puhlen orElseGet() takes a Supplier<T>, whereas orElse() takes a T. These are not equivalent.

[Fl0R1D3R]

that is partly true. findFirst() has following rule: "When there is no encounter order it returns any element from the Stream." -> so if your filter does not return the matched element, findFirst() will return the first one (except the stream is empty beforehand)

[Rorrim]

@bcsb1001 that's not what he tried to say, "getOrElse" is a name he invented to explain the purpose of orElse; there is no reference to orElseGet in his comment ;)

[lvoelk]

This is an accurate but deceptive statement as optionals still throw errors when accessed if they don't exist. From the perspective of avoiding null, all an optional does is change the error type as you still have to, in effect, null check it. In this case, what an optional provides is controlling where the null pointer error happens. Anyone who has had to debug null points while developing with streams knows this is very tricky to debug. Optionals allow us to pass this error to a higher level allowing us to target the issue precisely.

[Erwin Smout]

That was what I meant with "deal with it appropriately". If info can possibly be "absent" then for robustness of the code, the "presence" check has to be written somewhere (one way or another) but the point is that nullable objects make it too easy to just forget while if the typesystem explicitly tells you "Hey this is not a Foo but an optional, you have to .get() it first", then professionals might be reminded they have to do the "presence" check too and above all, they might be reminded that they should also be giving thought to what to do in the case the info sin't there.