• Tor Norbye’s blog
• Null Object Design Pattern

are absolutely spot on, although I would seriously contend the position that all null values are errors… for example, people commonly use null as a shorthand for “not found” (in the case of a Map-backed class, or “no more calls required” in recursive methods, which most certainly aren’t errors.

btw, Tor Norbye’s coding advice is a fantastic find.

But where null does become an option is, as a previous commentator mentioned, when there’s a database involved and the null could mean SQL null (as in no information in the DB)

But apart from that I agree - one should check for null parameters in public methods and never return null from a method call

-Frank

I just think that when you almost always need to catch exception and do something than it should be checked, but if not than it should be unchecked.

How do you feel about IllegalArgumentException ? I think that exception teach you that you should remember about unchecked you can always write in declaration “throws IllegalArgumentException”.

P.S. Thanks for Bruce Eckel’s article, but its too complicated for me, i just do

try { try { throw new FileNotFoundException(); } catch (FileNotFoundException e) { throw new RuntimeException(e); } } catch (Throwable e) { if (e.getClass().equals(RuntimeException.class)) { e.getCause().printStackTrace(); } }

its simpler

If you don’t like checked Exceptions, then check out ExceptionAdapter on Bruce Eckel’s article. It allows you to wrap any checked Exception into an unchecked Exception

That said, I would have to disagree about unchecked Exceptions for IO issues though. I believe unchecked Exceptions should only be thrown when it is impossible to recover, or when a class is implementing an Interface that doesn’t permit the kinds of Exceptions you have, and you can’t recover from it… indicating a major bug. In many cases it is possible to recover from an IOException… prompt the user for another file, or go to the next file in a list and log it.

We don’t code by metrics, but I find checked Exceptions (when checked! not simply dropped) produce much more stable code. We had a situation recently where we had changed a checked Exception into an unchecked one, and coded for a while. A week later, three unit tests started to fail. It wasn’t until we went digging that we realised we forgot that the method threw the unchecked Exception, and we’d forgotten to catch it… all in the name of code cleanliness. It’s these kinds of issues that prompted us to create this week’s poll!

In Map you have full control of what youre doing, i never use Map.containsKey() - i never needed it. If Map.get() returns null that means that it doesnt have the object that i wanted, i never want null from Map.

maybe i return null because all the try-catch’s make code look less readable(i hate checked exception because most of the time there should be unchecked exception - for example IOException should be unchecked(I always re-throw it or try to pass it to the method), FileNotFoundException also should be unchecked - if program fails when file is not found i dont care about catching this exception(i also never use it, because there is File.exist() method). However if your company is using metrics you should use checked exception more - because they produce more code(more code = less readable).

i hate metrics because they produce bad code, why should anybody write clean code when the more you write the better you are?

I’d like to hear you elaborate on what you mean by “normal processing”… some people hate dealing with checked Exceptions and other people (like me) hate dealing with null references. The problem with the former is that there is the temptation to ignore a checked Exception, whereas with the latter the problem is in forgetting to deal with it and revisiting the code doesn’t alert you to this.

If the null return value is actually a signal to an exceptional case (as you rightly point out), then I don’t see why an Exception shouldn’t be used, as it avoids unwelcome nulls hanging around.

As a side note, the performance overhead in throwing an Exception is so low these days that I wouldn’t even consider it an issue unless it was a mission critical class that was being used extensively in computational code. Life is too short to worry about optimisation at this level, unless you have a performance problem and profiling has pinned it down.

For example, not finding a key in a map is perfectly acceptable and part of the Map contract (it’s also quite frequent). Throwing an exception there would be an abuse.