When talking about implementing a result type in functional programming languages, many people remark that this can be implemented using an Either datatype. For example, in Haskell, the definition of Either is:

Either a b = Left a | Right b

All this means is an instance of Either a b is a Left a, or it’s a Right b. This datastructure is applicable to many use cases: one of them is representing the union of success and failure. For the case where it represents success or failure, a handy mantra is “Failure isn’t right”.

What that means is: for an Either a b, the success type is b and the failure type is a. This is true for two reasons.

Take a look at this code snippet - a Java puzzler from the classic book of the same name by Josh Bloch and Neal Grafter:

public class StrungOut {
	public static void main(String[] args) {
        String s = new String("Hello World");
        System.out.println(s);
    }
}

class String {
	private final java.lang.String s;

	public String(java.lang.String s) {
		this.s = s;
	}

	public java.lang.String toString() {
		return s;
	}
}

The answer is: it does nothing, and if you try to run it as a main method, you’ll get:

Exception in thread "main": java.lang.NoSuchMethodError: main

Why? Because a main method has to take an array of String, and ours takes an array of String, and…

Talking about code can often be imprecise. At times like that it’s nice to show the actual code, and also show what I want to talk about in it. Like this:

public class StrungOut {
	public static void main(String[] args) {
        String s = new String("Hello World");
        System.out.println(s);
    }
}

class String {
	private final java.lang.String s;

	public String(java.lang.String s) {
		this.s = s;
	}

	public java.lang.String toString() {
		return s;
	}
}

The problem is there are two String classes here: java.lang.String (in blue) and our own String class (in pink). main() requires a blue String, but it gets a pink String, so it’s not a main() method. But I don’t really care about the puzzler here: I want to talk about the highlighting.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965… My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

– Tony Hoare

Nulls are terrible. They’re dangerous and sneaky and they’re why Java’s type system is unsound. Ideally, we’d never use them, but we can’t do much about twenty years of libraries which might return nulls. At least we can try to stop returning them in our own APIs, because Java 8 gave us Optionals.

What’s an Optional? It’s a data type which represents either a value, or… not a value. This allows us to represent the possibility of an absence of the value in the type system. So, instead of code like this:

public static void helloKitty(Cat kitty) {
    if(kitty != null) {
        System.out.println(kitty.meow());
    }
}

We can write code like this:

public static void helloKitty(Optional<Cat> kitty) {
    if(kitty.isPresent()) {
        System.out.println(kitty.get().meow());
    }
}

The latter code is, to my mind, indisputably better than the former. The possibility of nullity is encoded in the types, and we can’t do anything to the cat without making a conscious decision to remove it from the Optional.

Intent is clearer. Mistakes are less likely. These are good things.

That said, don’t write code like this. Just because it’s better than the null-exposed version doesn’t make it good.