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

171–180 of 197 posts

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

#171

Post by [deleted] »

Gankro wrote: post #93
krisdol wrote: post #80

Earlier quoted context omitted.

>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

This seems a bit too unpragmatic. Would you also require the user to explicitly handle: * Index out of bounds on every array op * Integer overflow on every arithmetic op * OOM on every allocating op Maybe if you're writing an ironclad RTOS for a critical system without any good redundancy? Otherwise these are such pervasive operations that most have accepted that they're not worth handling everywhere they happen. Req…

[deleted]

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

#172

Post by krisdol »

steveklabnik wrote: post #163
fauigerzigerk wrote: post #161

Earlier quoted context omitted.

Can you name one such unconditionally unrecoverable problem?

Say you have a library which has some kind of internal state, and the consistency of said internal state is important for memory safety, as other operations rely on it. Using assert! to verify that your state is consistent is useful, in case you have a bug. But since it's all internal, it's not something that the caller can really recover from, either. It's not their fault, it's yours.

Well here's my issue with this explanation that I've heard a lot: the caller may or may not be able to recover from it, but the caller may still be doing something with the error. Maybe the caller doesn't want to expose the error to its caller, or maybe the caller wants to build a new message to explain the cause of your error. But to panic! takes away a lot of options for the caller.

Worst of all, it leads to untestable code, because the calling test case can't properly check the error against some known result.

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

#173

Post by krisdol »

Manishearth wrote: post #134
peeters wrote: post #127

Earlier quoted context omitted.

> If you use unwrap/expect/fromJust you are explicitly acknowledging that you want it to panic if it fails. If you use Optional.get() without Optional.isPresent(), how is that any different? It's not as nice as pattern decomposition, but it's still fundamentally the same, and on top of that, transform functions are provided so that most of the time you can do null-safe operations.

The difference is that Optional itself can be null, and in Java everything can be null.

But in Java you'd never use a library that calls System.exit when it reaches an unexpected null

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

#174

Post by Gankro »

krisdol wrote: post #172
steveklabnik wrote: post #163

Earlier quoted context omitted.

Say you have a library which has some kind of internal state, and the consistency of said internal state is important for memory safety, as other operations rely on it. Using assert! to verify that your state is consistent is useful, in case you have a bug. But since it's all internal, it's not something that the caller can really recover from, either. It's not their fault, it's yours.

Well here's my issue with this explanation that I've heard a lot: the caller may or may not be able to recover from it, but the caller may still be doing something with the error. Maybe the caller doesn't want to expose the error to its caller, or maybe the caller wants to build a new message to explain the cause of your error. But to panic! takes away a lot of options for the caller. Worst of all, it leads to untest…

Is this not a ridiculous thing for an application to check for? That the library it's using detected that it contains a bug?

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

#175

Post by Manishearth »

krisdol wrote: post #173
Manishearth wrote: post #134

Earlier quoted context omitted.

The difference is that Optional itself can be null, and in Java everything can be null.

But in Java you'd never use a library that calls System.exit when it reaches an unexpected null

See my other comment: https://news.ycombinator.com/item?id=10452408

In Rust you'd rarely write a library that panics on unexpected nulls.

(Also, panic != abort, yada yada)

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

#176

Post by codygman »

steveklabnik wrote: post #84
microtonal wrote: post #49

Earlier quoted context omitted.

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?

The definition in Rust's documentation[0] was this:

    let x: Option = None;
    assert_eq!(x.unwrap(), "air"); // fails
The equivalent Haskell if unwrap throws a panic as the docs[0] seem to imply:

    λ> fromMaybe (error "panic!") Nothing
    *** Exception: panic!
You could also do something like this if you don't mind dealing with the wrapped boolean value:

    λ> fmap (== "air") (Just "air")
    Just True
and the failure case:

    λ> fmap (== "air") (Nothing)
    Nothing
0: https://doc.rust-lang.org/std/option/enum.Option.html#method...

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

#177

Post by [deleted] »

codygman wrote: post #176
steveklabnik wrote: post #84

Earlier quoted context omitted.

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

The definition in Rust's documentation[0] was this: let x: Option = None; assert_eq!(x.unwrap(), "air"); // fails The equivalent Haskell if unwrap throws a panic as the docs[0] seem to imply: λ> fromMaybe (error "panic!") Nothing *** Exception: panic! You could also do something like this if you don't mind dealing with the wrapped boolean value: λ> fmap (== "air") (Just "air") Just True and the failure case: λ> fmap…

[deleted]

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

#178

Post by codygman »

kibwen wrote: post #166
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…

> much to my disappointment as I'm just learning rust Then prepare to be disappointed by Haskell as well, where the equivalent function is called `fromJust`. :P Both languages discourage the use of these constructs, but they exist for good reasons.

> Both languages discourage the use of these constructs, but they exist for good reasons.

Curious, what are your good reasons for fromJust in Haskell?

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

#179

Post by [deleted] »

Gankro wrote: post #174
krisdol wrote: post #172

Earlier quoted context omitted.

Well here's my issue with this explanation that I've heard a lot: the caller may or may not be able to recover from it, but the caller may still be doing something with the error. Maybe the caller doesn't want to expose the error to its caller, or maybe the caller wants to build a new message to explain the cause of your error. But to panic! takes away a lot of options for the caller. Worst of all, it leads to untest…

Is this not a ridiculous thing for an application to check for? That the library it's using detected that it contains a bug?

[deleted]

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

#180

Post by plonh »

eweise wrote: post #112
Kwastie wrote: post #18

The author is missing the point. The fact that Optional can result in a nullpointer doesn't mean you should use in the same manner as null-checks. You shouldn't replace: if(x == null) { y = x.doSomething(); } with if(optionalX.isPresent()) { y = x.doSomething(); } You should replace it with: y = Optional.ofNullable(x) .map(ClassX::doSomething) .orElse(null);

I agree. Having programmed in java for the past 15 years, I can attest that NullPointerExceptions are a constant source of errors. The main benefit I've experienced with Optional is that it documents the fact that a method might return a null value. Without this, the client has to guess whether or not to add defensive null checks.

@Nullable already does that.
Post reply on HN