Optional require(s) NonNull

[Ricky Clarkson]

> There is a big difference: with get(), the exception occurs at the
> exact location where you call get(), i.e. as soon as you need to pass
> your Optional value to some method that expects non-optional values.
> The problem with NPEs is not that they are thrown, but that they can
> be thrown far away from the code that actually caused them.

Optional can end up showing you a problem further away from the empty
than a null reference.  If you think you might later need to know why
an Optional is empty, then you have the wrong type (just as null is
bad for that use).  Either<Foo, SomeException> or conventional use of
exceptions might be better there.  I used to have my own type I
misleadingly called Option, which would contain a value or an
explanation of why it didn't contain a value, it could be worth
considering something like that if you need traceability.

On Tue, Oct 30, 2012 at 12:26 PM, Alessio Stalla
<alessiostalla at gmail.com> wrote:
> On Tue, Oct 30, 2012 at 4:02 PM, Roland Tepp <luolong at gmail.com> wrote:
>> 2012/10/30 Brian Goetz <brian.goetz at oracle.com>
>>
>>> Then what's the problem?  We have these methods already.
>>>
>>> You suggested moving get to Some/None, and Alessio told you exactly why
>>> that was a silly idea.
>>>
>>>
>> I actually suggested removing get() from Absent (NONE) and only moving it
>> to instances of Present and only Present.
>>
>> Pattern matching is not really an issue here, as most of the use cases
>> where you would use Optional, would need to deal with absent values by any
>> of the following ways:
>> 1. Use some sensible default value if optional is not present (this is
>> where I'd use optional.orElse(...) )
>> 2. Throw an exception if optional value is otherwise expected to be present
>> (i.e. optional.orElseThrow(...))
>> 3. Branch off logic based on the fact if the optional value is present
>> (checking optional.isPresent())
>>
>> The danger of having a get() method directly on Optional is that this
>> encourages the direct use of optional.get() which is susceptible to
>> NoSuchElementException with the same casualty as NullPointerException's are
>> common without use of Optional.
>
> There is a big difference: with get(), the exception occurs at the
> exact location where you call get(), i.e. as soon as you need to pass
> your Optional value to some method that expects non-optional values.
> The problem with NPEs is not that they are thrown, but that they can
> be thrown far away from the code that actually caused them.
>
>> Moving it out of the Optional and into the Some/Present will require
>> explicit casting of the Optional to Present which at least is more
>> deliberate action and force the developer to consider this at least for a
>> moment.
>> i.e. something like this:
>>     Optional<String> optional = ...
>>     if (optional.isPresent()) {
>>         ((Present) optional).get().split(...);
>>     }
>
> If you already bothered to guard it with if (optional.isPresent()) why
> the need for casting? And, if you don't guard it, it will fail with a
> CCE just as if it would have failed with a NoSuchElementException.
>
> --
> Alessio
>
> Some gratuitous spam:
>
> http://ripple-project.org Ripple, social credit system
> http://villages.cc Villages.cc, Ripple-powered community economy
> http://common-lisp.net/project/armedbear ABCL, Common Lisp on the JVM
> http://code.google.com/p/tapulli my current open source projects
> http://www.manydesigns.com/ ManyDesigns Portofino, open source
> model-driven Java web application framework
>