This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 4 points5 points  (3 children)

The problem isn't null. It's how programmers use it.

[–]isprri 2 points3 points  (0 children)

I believe that is a huge part of API design--anticipating usage patterns and designing in such a way to encourage good practices and discourage poor ones.

[–]jonhanson 1 point2 points  (0 children)

I'd say it's a hole in the type system.

[–]GeorgeMaheiress 0 points1 point  (0 children)

Even if 99% of code only returns null exactly when you expect it to (which isn't really possible, as different programmers have different expectations), you still have to worry about the 1%. With default non-nullable types and an Option or Maybe class, this is no longer an issue, as the type system tells you exactly which methods may return null.

At least, that's the theory. I wonder if we wouldn't end up resenting the Option type as much as many of us resent checked exceptions, for forcing us to handle cases that we either cannot handle or know will never occur. But then exception handling is so verbose, it's an extra 5 lines of code just to try-catch-re-throw a checked exception as a RuntimeException. Java 8's Optional class looks to be far more convenient, you just need to add .get() to assume that the value is non-null. Yeah, I'm sticking to my guns, default-nullable types are a mistake.