3 ms·

Simple answer: never return null. If something is wrong, throw an exception. If it's the kind of error that must be handled, throw a checked exception. If ther

by mabbo 10y ago

Simple answer: never return null. If something is wrong, throw an exception. If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty. The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc. But no one should ever have to check for null anymore.

JustSomeNobody 10y ago
Or use the null object pattern. Then you can write code that "just works"; kind of a higher level version of a nop.
- specialist 10y ago
  The Null Object pattern is The Correct Answer (for Java like languages). Java's Optional is a bad idea implemented badly made even more bad by bad usage.
  - mark242 10y ago
    Option is a takeoff of the Null Object pattern. Option(null).map(str => str + "!").foreach(str => println(str)) is a noop.
    - aarongolliver 10y ago
      Yeah, the Null Object Pattern is just optionals except you have to re-implement it each you need optional semantics.
    - specialist 10y ago
      No. They're opposites. "...an object which implements the expected interface, but whose method body is empty. " https://en.wikipedia.org/wiki/Null_Object_pattern https://en.wikipedia.org/wiki/Null_Object_pattern
gravypod 10y ago
"If something is wrong, throw an exception." That is sometimes just not an option performance wise yet. "If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty." Again, why is Optional.empty() better then null? What makes it better? What do you get from throwing an exception? What is the benifit. You can't just say "my way is better" when we have years and years of Java development flying contrary to your statement. What has changed that makes null a non-viable practice? "The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc." The code being cleaner is a subjective, or at least extremely difficult to prove, statment. For instance List<Integer> nums = getNumbers(); if (nums == null) { S.o.p("Failed to load numbers"); return; } for (Integer i : nums) System.out.println(i); Is far better then Optional<List<Integers>> nums = getNumbers(); if (!nums.isPresent()) { S.o.p("Failed to load numbers"); return; } nums.forEach(S.o::p); Or even better yet for (int i : nums) if (i < 10) S.o.p(i); VS nums.filter((n) -> n < 10).forEach(S.o::p); I don't think that's more readable. It think that's more compressed. HEre's another example. Suppose we have a magical language that I'm sure you'll pick up. It's a very compressed (or as you'd say expressive) language. This is that same code written in it pa(i i nums < 10) Which expands to "print all the ints `i` in nums that are less then 10" in english. That's far less readable. It is more compressed. I don't think compression is the goal of a language as much as it is a goal of a zip program. We're supposed to be writing software, not liturature to submit to the shortest story fully told contest. Readability is a function of correct verbosity. In my opinion. Just compressing your logic doesn't make it more readable. I think some verbosity is needed to preserve simplicity. "But no one should ever have to check for null anymore. " I mean that just doesn't make sense. If you're suggesting that there are some times the state of a program should never contain a null value is just ridiculous. Some things are correctly modled by null and some things are also too performance dependant to not use null. I think some things benifit from using Optional<> but the case doesn't exist to completely remove null. Even just by the creation of a new container object wrapping your already expensive return object there exists a case for null to exist. Just saying "Don't do it it's bad" is not proof. Saying "the code is cleaner, easier to read, etc" is not proof or even an example of a design that is simpler to pickup and get going with. You'd have to write some code with the Java/OOP paradigms and write a version (that is feature complete) with the FP paradigms and see which is easier to understand for a new programmer. I'd be hard pressed to belive that the FP implementation would be simpler. Maybe to you and me but no to someone without the domain specific knowladge required to understand what's going on. Even when I use map, zip, and list comprehensions in my python code it scares off some of my coworkers.
taneq 10y ago
But why returning Optional.empty better than returning null?
- ebola1717 10y ago
  It gives you a type/interface level guarantee. e.g. you know public Optional<File> loadFile(String filename); can fail to return a file, while public Int sum(Int a, Int b); can't fail to return an Int. Obviously, because nulls exist in java, this guarantee isn't provable on compilation the way it is in e.g. Scala, but if your entire team writes code this way, at least you can rely on that for internal libraries. Like generics, this is one of those ideas that's ok in java 1.X, but doesn't shine as much until a backwards incompatible java 2.X
  - eropple 10y ago
    Nulls exist in Scala. You can return null for an Option[T]. Can't in Kotlin, though.
    - kodablah 10y ago
      When interoperating with other libraries on the JVM you very easily can, which is a very common use case.
      - eropple 10y ago
        You're right. Kotlin provides the null-or-throw operator (!!) to convert a Derp? into a Derp, though.
  - deleted 10y ago
    [deleted]
  - Filligree 10y ago
    Nullable types provide Optional already. I find the use of a custom wrapper type to be a massive wart, and Optional is a common enough thing that it's worth adding a bit of syntax for it. Which is why I like Kotlin's approach. Same guarantees, one letter instead of ten. If you're writing Java, though, I can see why Optional has some use.

by mabbo 10y ago

JustSomeNobody 10y ago

Or use the null object pattern. Then you can write code that "just works"; kind of a higher level version of a nop.

specialist 10y ago
The Null Object pattern is The Correct Answer (for Java like languages). Java's Optional is a bad idea implemented badly made even more bad by bad usage.
- mark242 10y ago
  Option is a takeoff of the Null Object pattern. Option(null).map(str => str + "!").foreach(str => println(str)) is a noop.
  - aarongolliver 10y ago
    Yeah, the Null Object Pattern is just optionals except you have to re-implement it each you need optional semantics.
  - specialist 10y ago
    No. They're opposites. "...an object which implements the expected interface, but whose method body is empty. " https://en.wikipedia.org/wiki/Null_Object_pattern https://en.wikipedia.org/wiki/Null_Object_pattern

gravypod 10y ago

"If something is wrong, throw an exception." That is sometimes just not an option performance wise yet. "If it's the kind of error that must be handled, throw a checked exception. If there's no value to return, return Optional.empty." Again, why is Optional.empty() better then null? What makes it better? What do you get from throwing an exception? What is the benifit. You can't just say "my way is better" when we have years and years of Java development flying contrary to your statement. What has changed that makes null a non-viable practice? "The code receiving that Optional<Foo> is now free to do what the author is suggesting: map, filter, all without worrying if the value is actually there or not. The code is cleaner, easier to read, etc." The code being cleaner is a subjective, or at least extremely difficult to prove, statment. For instance List<Integer> nums = getNumbers(); if (nums == null) { S.o.p("Failed to load numbers"); return; } for (Integer i : nums) System.out.println(i); Is far better then Optional<List<Integers>> nums = getNumbers(); if (!nums.isPresent()) { S.o.p("Failed to load numbers"); return; } nums.forEach(S.o::p); Or even better yet for (int i : nums) if (i < 10) S.o.p(i); VS nums.filter((n) -> n < 10).forEach(S.o::p); I don't think that's more readable. It think that's more compressed. HEre's another example. Suppose we have a magical language that I'm sure you'll pick up. It's a very compressed (or as you'd say expressive) language. This is that same code written in it pa(i i nums < 10) Which expands to "print all the ints `i` in nums that are less then 10" in english. That's far less readable. It is more compressed. I don't think compression is the goal of a language as much as it is a goal of a zip program. We're supposed to be writing software, not liturature to submit to the shortest story fully told contest. Readability is a function of correct verbosity. In my opinion. Just compressing your logic doesn't make it more readable. I think some verbosity is needed to preserve simplicity. "But no one should ever have to check for null anymore. " I mean that just doesn't make sense. If you're suggesting that there are some times the state of a program should never contain a null value is just ridiculous. Some things are correctly modled by null and some things are also too performance dependant to not use null. I think some things benifit from using Optional<> but the case doesn't exist to completely remove null. Even just by the creation of a new container object wrapping your already expensive return object there exists a case for null to exist. Just saying "Don't do it it's bad" is not proof. Saying "the code is cleaner, easier to read, etc" is not proof or even an example of a design that is simpler to pickup and get going with. You'd have to write some code with the Java/OOP paradigms and write a version (that is feature complete) with the FP paradigms and see which is easier to understand for a new programmer. I'd be hard pressed to belive that the FP implementation would be simpler. Maybe to you and me but no to someone without the domain specific knowladge required to understand what's going on. Even when I use map, zip, and list comprehensions in my python code it scares off some of my coworkers.

taneq 10y ago

But why returning Optional.empty better than returning null?

ebola1717 10y ago
It gives you a type/interface level guarantee. e.g. you know public Optional<File> loadFile(String filename); can fail to return a file, while public Int sum(Int a, Int b); can't fail to return an Int. Obviously, because nulls exist in java, this guarantee isn't provable on compilation the way it is in e.g. Scala, but if your entire team writes code this way, at least you can rely on that for internal libraries. Like generics, this is one of those ideas that's ok in java 1.X, but doesn't shine as much until a backwards incompatible java 2.X
- eropple 10y ago
  Nulls exist in Scala. You can return null for an Option[T]. Can't in Kotlin, though.
  - kodablah 10y ago
    When interoperating with other libraries on the JVM you very easily can, which is a very common use case.
    - eropple 10y ago
      You're right. Kotlin provides the null-or-throw operator (!!) to convert a Derp? into a Derp, though.
- deleted 10y ago
  [deleted]
- Filligree 10y ago
  Nullable types provide Optional already. I find the use of a custom wrapper type to be a massive wart, and Optional is a common enough thing that it's worth adding a bit of syntax for it. Which is why I like Kotlin's approach. Same guarantees, one letter instead of ten. If you're writing Java, though, I can see why Optional has some use.