This post originated from an RSS feed registered with Java Buzz
by Ben Hosking.
Original Post: How should you deal with null's passed into methods
Feed Title: A Funny Java Flavoured Look at the World
Feed URL: http://businesslogs.com/WebLog/RSS.xml
Feed Description: The blog looks at using Java and programming in general as it pops up in life as a Java programmer. It will have links to interesting Java articles and resources. It will also have a lot of SCJP Java 1.5 information and links as I am currently studying
another day, another bug put in the system which has halted what ever development I was doing. This is a classic case of putting a fix into solve one problem and in it's place is one if not more bugs.
This is a slightly interesting bug. Basically we have a Utils Static/helper class and it has a removeFraction function. The function itself is pretty dodgy but basically you pass a String into the function but you know the String is really a number but as a String. This isn't to bad because a lot of variables are passed around as String or a good example is that the main method in Java accepts an array of String but the variables could be anything waiting for you to convert them.
The function then finds the index of the "." fullstop and then takes what's on the left (no rounding here). Although it's a tad dodgy it's not to bad .......Except when you pass a null into it. Now it is difficult sometimes to know what to do if some code tries to pass a null into your method, a lot of the time you could just say, well if you are stupid enough to pass me a null I am going to throw an exception and this is fair play at least you are warning code that calls your function what you might do. I thought of catching the null and passing it back as null but then this is not a good thing to do and more than likely you are just passing the bug on, unless the class you are passing back to has better exception handling.
I was disappointed that this problem had occurred because for this class I had created a unit test, so the developer added this method he could have easily added in a test. A good reason why you should add unit tests (along with all the others) is that when you are testing a function/method when you think about how you should test the function you often think about what should happen if some fool passes in a null but often when you don't write a unit test you never think that anyone would pass in a null, why would they do that.
I have read in effective Java and by a presentation on API both by Joshua Bloch that you should validate the values passed into a method and I think this is a prime example. By validating and dealing with wrong values and nulls inside the method it means that you will only have to have this code in once instead of all the code calling the method having to validate it.
In this example I have chosen to put a try and catch block around the code which tries to remove the fullstop, so if it is a null an error gets thrown and I have decided to return a zero which seems a fair trade a null for a zero. The one problem I did have was I wasn't quite sure where this badboy got called and the effect returning zeros might have. I have tested it and all seems to be working but you never can tell.
Previous Topic
