In an exercise where simplicity is requested and edge cases as well, it's virtually impossible to match expectations. This makes this exercise great.
My approach for not dealing with nulls, but still dealing with nulls, in a simple project like this, was this:
* There is no reference to nulls in the method javadocs, so they are not expected and therefore the behaviour is undetermined
* In an application using this library, as it was before the commit where these notes got added, the cases where nulls would be passed are extreme and arguably not something that should be dealt with at this level in an app
* Although I didn't add a test for it, I made sure that an NPE would be the exception being thrown
* Adding it properly to where it's needed is time-consuming. I have limited time to do these challenges so the compromise was to make sure the correct exceptions were thrown with the code I delivered
I tend to think and code for edge cases that stem from user error, not programmer error. NPEs, as any Runtime Exception, are to be avoided and functionality made to fail gracefully. They most often result from programmer error or hardware faults so... got to pick battles..
####An edge case I got wrong
Trying to finish a match that is no longer held by the library, or never was, seems like something a user would do by mistake and is definitely something that one such library should trigger an exception for, in general.
However, I did everything but add the javadoc throws tag for it. :) Added it now.
Trying to start a match with teams that are already in a game is another example. Or the same team as away and home.
However, in these I added everything but the unit tests for them.
Adding isInOngoingMatch(ITeam) and isOngoingMatch(IMatch) would also be nice helper methods to have. But..simple library.