Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So Optional.get() is similar to Rust's Option.unwrap(), right? A method with a short name, which newbies often use just more than they should, and which should only be used when it's a bug if the Optional/Option doesn't contain a valid value at that point?

(I still don't quite get the point of Optional; you're replacing a direct pointer with a pointer to a pointer, but the outermost pointer can still be null, so you are still vulnerable to a NullPointerException, and now you have two "not present" values to check for: null and !isPresent().)



> the outermost pointer can still be null, so you are still vulnerable to a NullPointerException

This is true, but there is a distinction: if your Optional value is null, for any reason, then it's a programming error and should be fixed. If a non-Optional value is null, there's no telling whether it's "allowed" to be null or not. So I never null-check my Optionals in Java -- I'd rather they fail so I can be alerted to them.


Sure, to be sure the type system needs to support non-nullable references. However, even without those, proper use of Optionals means getting a null result becomes an assertable bug in all cases, not a potentially valid code path signalling "not available" that should be checked.


It provides a migration path that allows deprecating null entirely. The next step is to deprecate methods like Map#get in favour of versions that return Optionals, ultimately arriving at a language where null can never happen when doing non-deprecated things. It's a multi-decade project but I don't see any other way to get rid of null while maintaining Java backward compatibility.


The point (or the reason why I use it) is to express the possibility of absent values, same as Rust, Haskell, etc. That the language let's you have null references is another (bigger) problem.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: