I don't think enumeration is the problem with handling error states, I think handling error states is the problem with error states. That is to say, there's no

I don't think enumeration is the problem with handling error states, I think handling error states is the problem with error states. That is to say, there's nothing wrong with null: There's something wrong with null-as-error, but it's not the blankness of the null that's the problem. The user is frustrated by this: Errors are fixable, so more important than more types and more maybes is that the errors communicate how to resolve them and what happens next: connection new_connection(address) { if(!address_valid(address)) return new_connection(prompt("The given address was not correct...", address)); ... Look: The user is prompted to correct the address in an interactive implementation, but a non-interactive (command-line) instance can implement prompt() as a combination of perror() and exit(). Then consider the following: * Start writing a large file * Run out of disk space * Delete the whole file and return an error The user has been frustrated by this for decades! It should be: again: ret=write(...); if(ret == -1) switch(errno) { case ENOSPC: wait(ENOSPC); goto again; ... and yet very few languages or environments have useful implementations of prompt() and wait() despite how trivial it is (even in C)! Even fewer libraries make shoehorning correct error handling in. Error handling just isn't part of our (collective) programming culture and if we're going to change something, we should fix it right.