actually that would be a bad idea.
considering you want to handle multiple options at once.
the code would get really messy with flatMap/map
another way would be (now consider more options and it will be way more ugly or considering a list of optional where every optional needs to be present to calculate something):<p><pre><code> if (opt1.isPresent() && opt2.isPresent() && opt3.isPresent()) {
int i1 = opt1.get();
int i2 = opt2.get();
int i3 = opt3.get();
}
</code></pre>
of course scala has a better way of handling that:<p><pre><code> for (i1 <- opt1; i2 <- opt2; i3 <- opt3) yield (i1, i2, i3)
</code></pre>
But java has no support for generators.
Edit: btw. even Scala has `get()` and it was there a long time even when you need it even less there: <a href="http://www.scala-lang.org/api/2.11.8/index.html#scala.Option@get:A" rel="nofollow">http://www.scala-lang.org/api/2.11.8/index.html#scala.Option...</a>
Having the get() method makes the entire purpose of Optional useless. All it does is make your null-checking code even more verbose. If you need to extract the value, the orElse method should be suitable on all cases. Deprecating get() should be an instant decision, since other than backwards compatibility it has nothing to add to the Optional class. Including it in the first place was as much of a mistake as the null pointer.
So, can anyone explain to me how this:<p><pre><code> Database.readOrder()
.map(OrderEngine::process)
.filter(ProcessResult::succeeded)
.ifPresent(Database::storeResult);
</code></pre>
Is more readable than the supposed "unpleasant old skool":<p><pre><code> Order order = Database.readOrder(); //can be null
if(order != null) {
ProcessResult result = OrderEngine.process(order);
if(result != null && result.succeeded()) {
Database.storeResult(result);
}
}
</code></pre>
Maybe I'm "old skool" but I find the second much easier to read than the first.
The name getWhenPresent() doesn't seem descriptive to me.<p>There is already orElse(value) and orElseThrow(exception), so why not add a plain orElseThrow() to raise the default exception?
I will never use Java's Optional. I'm baffled why it even exists. Further, I remain unclear on the value (haha) of the @Nullable and @NotNull annotations. If it's not baked into the language, why bother?<p>I've been using NullObject since (checking...) 1996. This is The Correct Answer.<p><a href="http://c2.com/cgi/wiki?NullObject" rel="nofollow">http://c2.com/cgi/wiki?NullObject</a><p>I first read about NullObject here:<p>Object-Oriented Design Heuristics
<a href="http://amzn.to/1ND1YSU" rel="nofollow">http://amzn.to/1ND1YSU</a><p>What'd be really neat is some mojo to remove the boilerplate of implementing NullObjects.
So Optional.get() is similar to Rust's Option.unwrap(), right? A method with a short name, which newbies often use just more than they should, and which should only be used when it's a bug if the Optional/Option doesn't contain a valid value at that point?<p>(I still don't quite get the point of Optional; you're replacing a direct pointer with a pointer to a pointer, but the outermost pointer can still be null, so you are still vulnerable to a NullPointerException, and now you have two "not present" values to check for: null and !isPresent().)
This kind of thing is so frustrating because enormous effort has been put into solving exactly one VARIANT of a pretty <i>general</i> problem. The general case is: at a <i>particular</i> point in the code, is $THIS_DATA usable or not, for some appropriate definition of “usable” in that code?<p>And if “usable” has <i>any</i> additional meaning besides “is not null”, <i>this entire machinery is useless</i> because one STILL has to figure out the state of the data!<p>For example, what if you are sanitizing input from a user and there is a “wall” in your code beyond which a string is considered safe (e.g. decoded, evaluated by regex, or whatever is supposed to happen)? Or, what if “usable” means that a server has been connected to, or a database opened, or a calculation completed, or whatever else you want to say? What if it’s a numerical denominator and you want it to be nonzero? The list could go on and on, and none of these architectures deals with ANY of those possibilities.
Love it!! As a Java 7 developer transitioning to Streams this made no sense to me and ended up doing the optional.isPresent() -> optional.get() ...<p>Took me to learn a pure functional language (Scala) to come back and start using map, filter, etc ... Not because Java 8 doesn't support it, but because a functional language community just has that mindset. There are many Java 8 developers using streams() and optionals with an imperative programming mindset still.
Not sure `getWhenPresent()` is better. Maybe `unsafeGet()`? That's a pattern found a lot on functional structures such as `IO` or `Task`.<p>There could be a discussion to remove `get` altogether, but I don't think it would be a good idea. I don't use the Java type, but `scala.Option` and I think `get` is occasionally helpful in unit tests, scripts, etc.