Avoid null: Use an Optional type instead

Did you know that “null” is a concept that had to be invented?   C.A.R. Hoare created it in 1965 as part of the Algol W language.  I think adding “null” to programming languages was a giant step in the wrong direction.  But you don’t have to take my word for it.  C.A.R. Hoare agrees with me and calls it his Billion Dollar Mistake. Since “null” had to be invented and Algol W wasn’t the first programming language, that means that there must be programming languages without the concept of “null”.  

But, how do they avoid this?  For example, what if you get some data from a database and the row is not there?  If a language doesn’t have “null”, how could it represent this state?  The answer is with the Optional type. In this article I’m going to explain in detail why you should prefer the Optional type (AKA the Maybe type) over “null”. But before I explain this, I want to explain what I dislike about “null”.

Continue reading

A weird Java trick for populating collections that you should never use!

A lot of people (myself included) complain about how verbose Java is.  This is especially true when it comes to populating collections from the Java Collection API.  Here’s what you typically see:

It’s frustrating that this is so verbose.  Wouldn’t it be better if you could do this common task in a concise way?  Well… there is actually a trick you can use in Java to do this.  It looks like this:

This has exactly the same result, but you should never do this:  This is difficult to read and most Java Engineers don’t even know how this works.  Then why did I decide to write an article about this if it’s a “worst practice”?  Well, it can be fun to know about tricks in Java that others don’t.  But more importantly, there is something to learn here.  What is this doing?  How does it work?  We are going to learn that and at the very end I’ll show you what code you should be using instead that’s the best of both worlds.

Continue reading

One man’s checked exception is another man’s run time exception

Recently, I was working on this project and I had just finished up the refactoring of it.  A colleague came over to review my code and he pointed out that there have always been a bunch of places that make remote calls and often fail in ways that are out of our control.  He wanted me to make sure we handle all of those situations.  The way this legacy code was written made that pretty difficult because these remote calls were made all over the place.

I realized that Java comes with a really good solution to this problem: Checked exceptions.  If you’re not familiar with checked exceptions, they are a way to force the code that calls a method to deal with the possibility that an error might occur.  Here’s an example:

In this case, FileNotFoundException  is a checked exception.  Because it’s a checked exception, my code is forced to deal with it or it will not compile.  On the other hand, the Integer  i  is null, but my code does not have to deal with that possibility when I call toString  on it.  This is called a run time exception because the error happens when I run my code (as opposed to when I compile it).

Continue reading

11 things I learned about TDD by looking at the tests in the JUnit source

JUnit is a unit testing framework for the Java programming language. JUnit has been important in the development of test-driven development, and is one of a family of unit testing frameworks which is collectively known as xUnit that originated with SUnit.

JUnit was originally written by Erich Gamma and Kent Beck. The latter literally wrote the book on Test Driven Development.  I thought it would be worthwhile to look at some of the tests in the library and draw attention to some interesting things about them because it may change people’s ideas of how to practice TDD.

Continue reading

The hashcode, explained

On StackOverflow, I was asked what the Java hashCode method does, but I did not have enough room to answer.  I decided to write a blog article about the topic.  The  hashCode method is a part of the Object  class.  This means that every single class in Java has a hashCode  method.  To explain what it does, I’m going to use an analogy:

Continue reading