Stop writing your code for the happy path

So Jessitron recently posted about avoiding cxceptions in Scala code using 'Either'. Mario Aquino followed up with an example of using Either in Ruby, and Heath responded with a post about the awkwardness of using Either in Java compared to using checked exceptions.

I agree with all of them on many levels. But the most important thing they didn't say (but which is implicit in their discussions), is the need to stop thinking that writing code is about implementing the happy path. It always amazes me when I encounter code base and discover how little thought has been put into the error handling (the "not so happy paths"). The truth is that about 10% of software engineering is implementing the happy path. The other 90% is figuring out how things can go wrong and then eliminating those possibilities (when feasible) or writing code that gracefully handles the errors.

The art of system design is in finding ways to simplify the code that handles all the errors that can occur. The happy path code can never get any shorter than the minimum required. It's all the error handling code that leaves room for good design.