Maybe
One of the more hideous quirks of the family of programming languages derived from C is the fact that values of pointer based types may be NULL. This means that a simple code fragment like this:
String s = find(input,token); if (!s.empty()) { // do something }
might segfault or throw an exception. You need to write something more like this:
String s = find(input,token); if (s != null && !s.empty()) { // do something }
This is the root cause of the most common bugs I’ve seen in C, C++, and Java code, but a lot of developers in those languages seem to think that it’s just a fact of life that you have to accept.
A number of languages don’t have this problem. They simply don’t allow NULL values for these types. It turns out that it’s possible to throw the baby out with the bathwater when you go that direction. In the example above, find might really want to distinguish between finding an empty string and not finding any string at all. You can work around this with a second return value, but the result is pretty ugly. Something like returning NULL is actually cleaner in this case. But does seem crazy to burden everyone who uses strings with null pointer exceptions just because of this one use case.
Several recent languages have done a better job of balancing these two concerns. One noteworthy example is the Maybe type in Haskell, but there are good examples in a number of other languages.
Guy Steele just posted a very thoughtful article on his blog about this problem and how they approached it in Fortress.
Their basic approach is that the Maybe type is a mixin. This means that you can create a type that is either a String or nothing without forcing that option on everyone who uses strings.
One nice feature of his post is that they really chased down the loose ends. They realized that the Maybe type is related to a collection in many ways. But that it is a collection which can only have 0 or 1 items in it. If collections like that are important (and they are if you introduce Maybe), then that has implications for everything that deals with collections. For example, there’s a nice if/else syntax for this type of collection.
If you’re interested in programming languages and the ins and outs of designing datatypes, you should go read it.
As a counterexample to the Fortress approach described above, some of the methods in the new java.lang.Objects class in Java 7 is a good example of how bad things look when you try to deal with null handling after the fact.