Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java 8’s new Optional type doesn't solve anything

medium.com

Post reply on HN
Print view View original

81–90 of 197 posts

Re: Java 8’s new Optional type doesn't solve anything

#81

Post by aljones »

microtonal wrote: post #29
vbezhenar wrote: post #16

I don't understand what's wrong with get() method. Swift has built-in null-safety and it has "!" operator. Kotlin has it. Even Haskell has fromJust function which does exactly the same. May be name "get()" is too short and innocent-looking.

Partial functions such as fromJust are generally frowned upon in the Haskell community. There was a relatively recent proposal to deprecate and then remove fromJust: https://mail.haskell.org/pipermail/libraries/2015-February/0...

The equivalents are not celebrated in other languages.

Re: Java 8’s new Optional type doesn't solve anything

#84

Post by steveklabnik »

microtonal wrote: post #49
krisdol wrote: post #45

Earlier quoted context omitted.

>tl;dr: Haskell, Rust, et al. put the burden on the compiler. Java puts the burden to ensure safety on the programmer. (As can be witnessed in your snippet.) Actually, (much to my disappointment as I'm just learning rust) you can just take an Option or Result and .unwrap() and the compiler won't complain at you for not checking it. For such a "safe" strongly-typed language, I'm surprised that so much new rust code do…

Allowing unsafe unwraps defeats a core purpose of rust, Definitely, but you can also still do this in Haskell ( fromJust ). But it's better than nullable types since you explicitly have call an unsafe method. (Assuming that you have set non-exhaustive pattern matching to be a warning/error.)

unwrap() is not unsafe in Rust, and I don't think Haskell has anything similar?

Re: Java 8’s new Optional type doesn't solve anything

#85

Post by steveklabnik »

krisdol wrote: post #80
Gankro wrote: post #73

Earlier quoted context omitted.

Just to clarify since `unsafe` is a special term in Rust: `unwrap` still checks for None and panics, it doesn't blindly assume it's valid. That said, I think you're too dismissive of "can never fail" assumptions. There's tons of places where something is optional in general, but based on various invariants you know it won't be. For instance, if you successfully acquire the first element in an array, you know you can…

>Gonna have your function return an Err if an internal invariant is broken? Absolutely you should return an error. Whether the caller wants to panic or handle it or print unicorns should be left up to the caller, not your function. Functions should not be expected to tear down the thread in case of an error. Nothing that panics should belong anywhere in exported code

The idea is that Err is good if it's a recoverable error, but if it's not recoverable, you should panic!.

Most errors are recoverable. panic! is an antipattern in a library. Or at least, provide both a panic-ing and a non-panic-ing variant.

Re: Java 8’s new Optional type doesn't solve anything

#86

Post by tel »

matteotom wrote: post #52

I don't program much Java, but how expensive are exceptions? Wouldn't it make more sense to expect functions that could return null to instead throw a checked exception if something goes wrong? eg public dbResult doDatabaseThing(stuff) throws DatabaseException So if you do result = doDatabaseThing(stuff) the compiler will require you to do something about the DatabaseException. It seems to me that the point of, for e…

And of course checked exceptions (wrapped in a try block) are "just" the nomadic effect of the option (or "result") type.

Re: Java 8’s new Optional type doesn't solve anything

#88

Post by Sharlin »

MereInterest wrote: post #70
jontro wrote: post #19

Earlier quoted context omitted.

Exactly, it forces the programmer to think about whether something can be null or not and actually had a behavioural change in my java coding.

Wouldn't it be better to have a non-nullable type, akin to C++'s return by value? That way, instead of forcing the programmer to think, you are removing the problem that they would need to think about.

Or, indeed, C++'s references which are non-nullable.

Re: Java 8’s new Optional type doesn't solve anything

#89

Post by bkv »

jcrites wrote: post #5

The lack of pattern matching doesn't make it useless. The existence of Optional reminds the programmer to check whether the value is present, and the type system does enforce this; you can't accidentally treat an Optional as a reference of the same type. The type system does help us remember to handle things; it is a reminder enforced by the type system that's easy to examine during code review. Yes, you can write ge…

>Yes, you can write get() and risk an exception. So don't do that.

Yes, you can dereference a null pointer and risk an exception. So don't do that.

See where this is going?

The problem with Java's optional is that it is by all appearances (in name and high-level description), a general purpose optional, albeit with a ton of gotchas that will result in people saying "Just don't do that."

Java's optional is not a general purpose option type. In fact, its intended use-case is very specific, according to a rather obscure SO answer by Brian Goetz: http://stackoverflow.com/a/26328555/547365

This is, of course, just tribal knowledge, meaning people are going to be doing shit with optional that they shouldn't, and it's going to be messy.

Re: Java 8’s new Optional type doesn't solve anything

#90

Post by Sharlin »

jrockway wrote: post #62

I've only used the Guava version of Optional, which appears to have a slightly different API than Java 8's. (You can tell there's a Java 8 committee, that's for sure.) The biggest problem I found in applying Optional is that Optional is very much a Haskell-y concept to me, and Java programmers and Haskell programmers don't really overlap much. Therefore, to me, Optional is just a functor like a list or a set. So doin…

> Except that Haskell automatically preserves the type safety, whereas you have to re-wrap the value if you're using Java.

Optional has map() in Java.

  Optional result = Optional.empty().map(i -> i * i);
  assert(!result.isPresent());

  Optional result = Optional.of(9).map(i -> i * i);
  assert(result.get() == 81);
Post reply on HN