51–60 of 197 posts
I have the same feeling about boost's optional. It's a bandage on a wooden leg.
eg
public dbResult doDatabaseThing(stuff) throws DatabaseException
result = doDatabaseThing(stuff)
It seems to me that the point of, for example, Option and Result in Rust is to avoid the whole checked exception mess while still passing useful information about things that go wrong. But, given the problems pointed out in this article (lack of pattern matching and algebraic data types mostly), checked exceptions might be a more correct way to do it in Java.
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…
Without exceptions you would have to return a value that could discriminate between all 3 possible outcomes: nothing, error, result. In Rust this is the `Result` struct.
Shameless self plug "Comparing Optionals and Null in Swift, Scala, Ceylon and Kotlin" http://codemonkeyism.com/comparing-optionals-and-null-in-swi...
FYI your Scala example doesn't work. Welcome to Scala version 2.11.6 (Java HotSpot(TM) 64-Bit Server VM, Java 1.8.0_45). scala> var h:Option[String] = "Hello".some :7: error: value some is not a member of String var h:Option[String] = "Hello".some
var h: Option[String] = Option("Hello")
import scalaz._, Scalaz._
var h: Option[String] = "Hello".someEarlier 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.
> Exactly, it forces the programmer to think It's a curious feature, the way you've described it. I have virtually no experience with Java so I'm looking at this from a totally foreign perspective. The authors considers it an ineffective feature because you still have to think about null checks, whereas you consider it an effective feature because it forces you to think about the problem instead of ignoring it.
Earlier quoted context omitted.
I disagree with some of your points. The fact that you can get a null instance of Optional is not Java specific - Scala has the same issue, for example. Saying that Optional does not sort any problem because there is no way to enforce it cannot be null is just wrong - it sorts plenty of problems, just not all of them (you didn't mention the case of an optional that contains null, which is unpleasant as well). You can…
> you didn't mention the case of an optional that contains null That's not possible in Java. `Optional.ofNullable(null)` returns `Optional.empty()`, and `Optional.of(null)` throws a NullPointerException.
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…
Yes. In this case the No-result means that the database query was successful, but no record was found. A connection error etc. should almost certainly still be thrown as an exception in Java. Without exceptions you would have to return a value that could discriminate between all 3 possible outcomes: nothing, error, result. In Rust this is the `Result ` struct.
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…
Earlier quoted context omitted.
Yes. In this case the No-result means that the database query was successful, but no record was found. A connection error etc. should almost certainly still be thrown as an exception in Java. Without exceptions you would have to return a value that could discriminate between all 3 possible outcomes: nothing, error, result. In Rust this is the `Result ` struct.
It that case, wouldn't it be better to return something other that `null` for no-result (an empty iterator? an empty list?)? That might be where Optional comes in, but I'm still not sure why a new language feature is needed for that.
Earlier quoted context omitted.
The problem is that you don't get guarantees that something is not null; you can still do Optional myOptional = null. Second, you're not required to handle the not-present case. Third, if you attempt to get the value of an optional (using .get()) when it is not present, you get an (unchecked, so no requirement to catch) exception - basically replacing NullPointerException with NoSuchElementException. The only value O…
> Optional myOptional = null That hasn't been a problem for me in practice. It's pretty clear that a reference to Optional should never be null. It can be statically or dynamically checked with @Nonnull or a precondition. > but the same was true for nullable properties. It's inconvenient to have to treat everything as possibly null. It's a lot nicer to create the convention, within one's codebase, that references are…
It has for me. Functions have multiple return points, some of them returning "null". Lead developer insists we use Optional to clarify that these functions can return null. People go over the function, replacing each instance of "return null" with "return Optional.empty()", but forget some instances. Now we have Optionals that are sometimes null.