Win a copy of Classic Computer Science Problems in Swift this week in the iOS forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

About Optional<T> and its usage  RSS feed

 
Ranch Hand
Posts: 973
9
IBM DB2 Java Netbeans IDE Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe I didn't fully understand the value of this new feature, but honestly I'm having hard times to figure out how and when to use it.
I created a simple class, Item:



and a trivial class, OptionalUsage, to play with Optional:


In Optional class, I coded two very simple methods, to find a given Item in a collection (Ok ok : with Streams,  I won't need to write such methods by hand anymore; assume mine as a toy class).
With respect to input parameters, my feeling is that it would be generally speaking better to continue to use "plain" parameters, i.e. without using Optional<T> at all, and let method code to use Optional as "syntactic sugar"  to handle potential null references.
In my example, I preferred old style null checking; I could write as well (If I could assume that a null list is equivalent to an empty list) :



or, again using old-style ternary operator:



Moreover, in my humble opinion, using Optional as parameters at least in public methods  a) create boilerplate code b) it doesn't prevent at all to pass nullable Optional values:



With respect to returned values, I think Optional may be useful to warn class users to be aware that a method may return an unitialized (or null) value and force them to proper check for null values.
For example,  I could write:



These are my two cents.
What do you think about ?
 
Sheriff
Posts: 21305
87
Chrome Eclipse IDE Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that you shouldn't use Optional as input arguments (with perhaps the odd exception here and there). If the item to search for or list is null, let the calling code handle how to deal with that. Using Optional for the return type is indeed warranted, and should have been used in old methods if it were available at the time.

One thing though: Optional.ofNullable(null) is effectively the same as Optional.empty(). Which actually is a reason it makes sense to disallow null for the item as well as the list; right now you couldn't see the difference between no match or a null inside the list, both return an empty Optional.

Oh, and a NoSuchElementException is a better choice than a regular Exception.
 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I imagine a world where I don't have to do any null checks and be wary of NullPointerException. I personally use for return type where if the value is not present then an exception is not mean to be thrown. Allowing Optional as arguments or return type lets the developer know the intention of interface/method.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!