• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

About Optional<T> and its usage  RSS feed

 
Ranch Foreman
Posts: 1026
24
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: 21466
97
Chrome Eclipse IDE Java Spring Ubuntu VI Editor 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.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!