Home.... | log in.... | Pub my question! | Sign-up....
Java-index >> Other Topics >> Patterns & OO Design

null checks

Hi all,While designing an application, what are the basic guidelines for the following:1. when to make a NOT NULL check on objects. 2. when to throw an exception in case of an object being null, in a use case flow.Thanks in advance.
[267 byte] By [kollareddya] at [2007-10-3 1:03:33]
«« Problem with java
»» Memory Usage
# 1
Also how to decide as when a method must return null or throw an exception instead?
kollareddya at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
# 2

> Also how to decide as when a method must return null

> or throw an exception instead?

I had to ask myself this very question not so long ago, and I can give you those advices:

1) Try to avoid that your object can become null as far as possible. The keyword "final" is very helpful in this. When designed right, you don't have to check for null at all (or at least, very seldom).

2) Don't use exceptions for situations that can regularly occur. They are meant to be called very rarely. Also, you should ONLY call them, when you can't solve your problem at this point.

For example, if you write a file to harddrive, and you get an IOException, there is not much you could do right now. You have to forward the exception to some point where you can actually do something reasonable - in many cases, this will end up at the user interface, asking the user to save the file somewhere else.

So, when you expect the object to be null at some point, you should do something about it. If you can't do anything, you should throw an exception. But DON'T use exceptions for simple signalling. They are way to complex and expensive to use them like that.

Mongera at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
# 3

I usually have methods that return different things based on the parameters recieved. Sometimes the parameter value is not one you expected and you don't know what to return. Some people return null in that case, but I prefer thriwing IllegalArgumentException. Let me show you an example.

class Country {

public static Country getInstance(String countryCode){

Country answer = COUNTRY_MAP.get(countryCode);

if(answer == null){

throw new IllegalArgumentException(

"The country for code "+countrycode+" does not exist.");

}

return answer;

}

}

In this way during developement and testing you find out if the data you are dealing with references countries you did not add to the map.

If you expect to ask for countries that don't exist and want to do something with that it is preferable to return null or use the NullObject pattern (a Country subclass that represents the NotFoundCountry). Returning null forces the caller to handle the situation, returning a NullObject allows callers to delegate on it the handling of certain situations.

I used NullObject to model failed results of a calculation. If for whatever reason a calculation did not return a valid result I return a NullObject that I called UnpricedTicketResult that has an error code and a message string. The object that handles proper results also handles the other so I don't have to make an if and both possible outcomes are dealt with normally.

fedetxfa at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
# 4
assert
mchan0a at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
# 5
If its a public method meant to be called from code compiled by someone else, then I throw NullPOinterException if the argument is null and I can not handle null argument. Else I assert.
_dnoyeBa at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
# 6

> Hi all,

>

> While designing an application, what are the basic

> guidelines for the following:

>

> 1. when to make a NOT NULL check on objects.

when you don't want it to be null?

or when you want it to be?

check whatever you want, whenever you want

what are you saying?

> 2. when to throw an exception in case of an object

> being null, in a use case flow.

when it's desireable? i mean, you're not making much sense.

if an object is null, and it ain't supposed to be null, then throw an exception, if you want, or code the flow any way you want

there is no standard for this kind of stuff

SoulTech2012a at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
# 7
> assertasserts can and should be turned off at runtime. that's not the right way to do it.%
duffymoa at 2007-7-14 17:59:47 > top of Java-index,Other Topics,Patterns & OO Design...
Other Topics
Patterns & OO Design

Other Topics New Topic

Other Topics Hot Topic

Other Topics

All Classified