Forget Optional<T>, adopt Try<T>?

[Zhong Yu]

I'm thinking that if we have something like scala's Try<T>, it'll
express APIs' intentions better than Optional<T>.

Some people view Optional as a collection of either 0 or 1 element.
That doesn't seem to be what an API author wants to express by
returning an Optional. The actual intention is that, either the action
succeeds with a value (not a collection of!), or it fails (with an
unspecified or implied reason). Try<T> describes that intention
precisely (but it probably needs a better name)

Suppose we have a good old method that returns a nullable

    /** return null if there's no element */
    T getFirst();

Why do we hate it? Probably because we need to insert null handling in
the code path

    T first = getFirst();
    if(first==null)
        blah blah
    first.doSomething()...

we would rather defer null handling to some later time, leaving the
main code path cleaner. Java already has a way to do that - exception
propagation. For example the method can be designed to throw

    T getFirst() throw NotFoundExcpetion;
    // for efficiency, throw a cached immutable exception object

    T first = getFirst();  // may throw - exception will be handled
somewhere else
    // no null handling here
    first.doSomething()

But lots of try-catch blocks may make code look ugly. Try<T> may be nicer

    /** fail with NotFoundException if  there's no element */
    Try<T> getFirst();

    Try<T> first = getFirst();
    first.map().filter().recover()....

So we don't need Optional. Try<T> does the same thing, and expresses
the intention better. And Try<T> has broader use cases. It'll also
appease those who prefer returning errors over throwing errors.

Sounds good?

Zhong Yu