Forget Optional<T>, adopt Try<T>?
zhong.j.yu at gmail.com
Mon Jun 3 21:21:54 PDT 2013
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 */
Why do we hate it? Probably because we need to insert null handling in
the code path
T first = getFirst();
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
// no null handling here
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> first = getFirst();
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.
More information about the lambda-dev