Hacker News Reader

Comment by bakhy | Hacker News Reader

some have already commented here that author maybe complains too much (e.g., calling .get() on an Option<T> is a deliberate move, meaning that the developer explicitly took on the risk of that exception. that's very different than implicitly assuming that a regular ref is not null, using it and getting bitten in the ass.). but this one really hurts:

"The last flaw with Java's implementation is a bit ironic — It's possible for the optional reference itself to be null."

ouch.

View on HN

This is another off-base point, in my opinion. Sure, it's possible for it to be null, and that isn't great - but the vast majority of null problems come from the user assuming the interface won't give you a null. Something returning an Optional should never return null, so the ambiguity is resolved. Sure, it still could as a bug, but that's actually a pretty rare case. I don't see it being a real problem.

that makes sense. i think an important question here is - what does "return null" in a method which returns Optional<T> do? will it return a null Optional<T>, or will it return a non-null Optional<T> which is empty?

sorry to rub it in, but Java needs value types. this whole issue, however maybe irrelevant, does not exist in C#.

It's a very simple question to answer: "return null" returns null.

then this abstraction has sprung a serious leak. the article seems to be fully right.

The point is that wherever that happens, it's an obvious flaw with the method returning the null, and can also be caught by static analysis. It means that in general, the problem is avoided.

Yes, it's not ideal, it's still a flaw that should be caught at compile-time, but it's not a big real-world problem, as returning null by accident instead of an option is a pretty rare bug.

The much more common bug (you didn't realize no return value was a case), the Option is a good counter to.

No, it's not a perfect solution, but it's not useless either.

i understand, and agree. i would personally, though, avoid adding it, and add attributes for the same purpose instead. just as the article suggests... it achieves the same without introducing a new class, thus also remaining backwards compatible.

Exactly. A null Optional reference is such an obvious bug, that it can easily be detected by simple analysis tools. OTOH, a null is often an accepted (if derided) method of indicating that a value simply doesn't exist, so it's much more difficult to detect when a null will cause a problem.

That the reference can be null is hardly the fault of the implementation of Option in Java,unless people expect individual classes to modify the type system.

Reply on news.ycombinator.com