5 ms·

Only if you never have the case where Optional is empty but you expected it not to be. How often is Optional.get or orElseThrow called blindly? How often is boi

Only if you never have the case where Optional is empty but you expected it not to be. How often is Optional.get or orElseThrow called blindly? How often is boilerplate code written which checks if the optional is empty and then throws "should not happen" exception or just logs a message? Once NullPointerException got "helpful" messages, I don't see that much advantage to Optional, considering that it provides less information out of the box.

convolvatron 5y ago
for me this is one of the bigger festering wounds in programming. error handling doubles the size of the code. error handling is complicated. so we put on our big-dev pants and build all sorts of structures around handling errors to make it more sound/ergonomic. but at the end of the day: o its still very difficult to respond in a semantically meaningful way to errors as code o they still almost always just get dumped into a log or ignored, or just result in a panic o even if we have managed to surface them - they still aren't really that actionable by the end user so we haven't helped the situation much, but some of these answer like catch/throw have really unpleasant consequences - we may have made it worse
- valenterry 5y ago
  It's pretty much a solved problem. Just use a language that has better ergonomics for errors. Scala's ZIO is one of the better examples if you are interested to look into an alternative.
esrauch 5y ago
> Only if you never have the case where Optional is empty but you expected it not to be I kind of think that sentence is contrary to the point of Optional, and if you start from that mindset then Optionals do end up no better than nulls. Instead you enforce good hygiene where you unwrap early and pass non-Optionals for anything that you "know" is non-null. If you call a function which returns optional, and you're find yourself thinking "nah, I _know_ this is definietly non-empty" then you're incorrect; the API explicitly is telling you that it definitely can be empty.
- hashmash 5y ago
  There are certainly cases where Optional is better than a "this can be null" comment, but consider the possibility that the Map interface was designed to always return Optional. If I'm using a Map that I have complete control over, that I know what's in it (I think), then I'll call Map.get(x).orElseThrow(). This isn't an improvement over a Map.get(x) call that can return null. It's also uglier, and as shown by the Rust benchmark, much slower. I'd be happier with a Map interface that had a "tryGet" and "get" pair, where only the latter threw an exception. No need for Optional.
  - valenterry 5y ago
    It _is_ an improvement. If you just do "Map.get(x)" and you get null because your thinking was wrong, then the NPE will pop up potentially 10 layers later or an hour later, when the null-value was tried to be used in your program. On the other hand, with "Map.get(x).orElseThrow()" you will have an exception thrown immediately! Even better, you should customize that as "Map.get(x).orElseThrow(NoSuchElementException(x))" so that you know the value that was unexpectedly not in the list. That will make debugging much easier and will potentially fail a test case while a "Map.get(x)" might not cause the test to fail.
thinkharderdev 5y ago
The advantage is if you are explicitly modelling a value that could be empty. You can encode that into the type system by making git an Option<T> instead of just a T (that could be null). At it's most basic level it can just help reduce the possibility of NullPointerExceptions but the real benefit and reduction of boilerplate comes when you use Option as a monad. For instance, in Scala if you have a something like case class Address(street: String, city: String, state, String) case class User(id: Int, name: String, address: Option[Address]) def filterCAUsers(users: List[User]): List[User] = users.filter(_.address.exists(_.state != "CA"))

convolvatron 5y ago

for me this is one of the bigger festering wounds in programming. error handling doubles the size of the code. error handling is complicated. so we put on our big-dev pants and build all sorts of structures around handling errors to make it more sound/ergonomic. but at the end of the day: o its still very difficult to respond in a semantically meaningful way to errors as code o they still almost always just get dumped into a log or ignored, or just result in a panic o even if we have managed to surface them - they still aren't really that actionable by the end user so we haven't helped the situation much, but some of these answer like catch/throw have really unpleasant consequences - we may have made it worse

valenterry 5y ago
It's pretty much a solved problem. Just use a language that has better ergonomics for errors. Scala's ZIO is one of the better examples if you are interested to look into an alternative.

esrauch 5y ago

> Only if you never have the case where Optional is empty but you expected it not to be I kind of think that sentence is contrary to the point of Optional, and if you start from that mindset then Optionals do end up no better than nulls. Instead you enforce good hygiene where you unwrap early and pass non-Optionals for anything that you "know" is non-null. If you call a function which returns optional, and you're find yourself thinking "nah, I _know_ this is definietly non-empty" then you're incorrect; the API explicitly is telling you that it definitely can be empty.

hashmash 5y ago
There are certainly cases where Optional is better than a "this can be null" comment, but consider the possibility that the Map interface was designed to always return Optional. If I'm using a Map that I have complete control over, that I know what's in it (I think), then I'll call Map.get(x).orElseThrow(). This isn't an improvement over a Map.get(x) call that can return null. It's also uglier, and as shown by the Rust benchmark, much slower. I'd be happier with a Map interface that had a "tryGet" and "get" pair, where only the latter threw an exception. No need for Optional.
- valenterry 5y ago
  It _is_ an improvement. If you just do "Map.get(x)" and you get null because your thinking was wrong, then the NPE will pop up potentially 10 layers later or an hour later, when the null-value was tried to be used in your program. On the other hand, with "Map.get(x).orElseThrow()" you will have an exception thrown immediately! Even better, you should customize that as "Map.get(x).orElseThrow(NoSuchElementException(x))" so that you know the value that was unexpectedly not in the list. That will make debugging much easier and will potentially fail a test case while a "Map.get(x)" might not cause the test to fail.

thinkharderdev 5y ago

The advantage is if you are explicitly modelling a value that could be empty. You can encode that into the type system by making git an Option<T> instead of just a T (that could be null). At it's most basic level it can just help reduce the possibility of NullPointerExceptions but the real benefit and reduction of boilerplate comes when you use Option as a monad. For instance, in Scala if you have a something like case class Address(street: String, city: String, state, String) case class User(id: Int, name: String, address: Option[Address]) def filterCAUsers(users: List[User]): List[User] = users.filter(_.address.exists(_.state != "CA"))