Programing Technique question - Try or If

[TimHuey]

I have snippet of code that has the possibility of generating a nullpointerexception. Here is the code:

ArrayList overnightCities = ((SeqObject) seqHashTable.get(String.valueOf(seq))).getCities();

If the item exists in the hastable it is retrieved. If it doesn't, it generates a nullpointerexception. A miss keyed data file can cause the item to not be created. In the past I've tested before I issued the assignment command with:

if (seqHashTable.containsKey(String.valueOf(seq))) {

A try Catch block would do just as well. Which is the preferred method of coding the possible error.

[Singing Boyo]

personally, I go with the if method of handling it, as I've been told try-catch blocks can create large overheads, and also because I've had difficulty catching RuntimeExceptions, notable ClassCastExceptions (so I use if (var instanceof MyClass) instead of a catch block). However, this is really just my personal preference.

[TimHuey]

Thanks Boyo, I like the idea of keeping the overhead down.

[Tolls]

Thanks Boyo, I like the idea of keeping the overhead down.

You shouldn't worry about any perceived overhead. You should code in a way that makes sense, logic-wise.

In your case, is it an error if seqHashTable.get(key) returns null?

In this situation, though, all you need to do is check for null. Try not to squeeze too much onto a single line:

ArrayList overnightCities = ((SeqObject) seqHashTable.get(String.valueOf(seq))).getCities();

should probably be:

SeqObject seq = seqHashTable.get(String.valueOf(seq));
if (seq == null) // Do something here, maybe throw exception?
ArrayList overnightCities = seq.getCities();

What you do in the if is entirely dependent on the structure of your code. Since this will likely be a simple method an exception here might be a reasonable choice. It would probably be mine.

[TimHuey]

Thanks for the heads up on one big line of code. I was wondering that as well. "If you can squeeze everything into one line, should you." The second parsed out way is more readable but not as glamorous. I don't know much about programming or Java and any chance I have of showing some sibilance of prowess I jump at. I have several instances where I grab an seq object like that and as a matter of fact here is some code from my program:

displayaline((String) ((JList) evt.getSource()).getSelectedValue()); //Wow, evt.getSource retrieves the object that experienced the EVENT, then since you know it will be a JList
                                                          //you cast it as (JList) that way you can access the functions of the JList item, namely ".getSelectedValue()"
                                                          //that returns the value that you just mouseclicked on. Since we know it will be a String we castit as (String)
                                                          //all this is seperate out below but Ithought I would try and combine into one statement, you know for fun!
//    JList temp = (JList) evt.getSource();
//    String lineselected = (String) temp.getSelectedValue();
//    displayaline(lineselected);

As you can see from above I bounced back and forth trying to decide which way to retrieve the object. I will stretch things out a bit from now on.

[Tolls]

I prefer open code.
It's easier to debug, and easier to maintain (as in your null problem above).
There are times when a oneliner is OK, the Hibernate Criteria stuff immediately springs to mind, but in that case you know what you've got (no nulls to bite you) since you're simply adding things in.
eg:

criteria
	.add(Restrictions.eq("userId", userId))
	.add(Restrictions.ge("orderDate", fromDate))
	.addOrder(org.hibernate.criterion.Order.desc("orderDate"));

[TimHuey]

Well, your right Tolls, and I am writing this software in the hopes that others where I work will take up the torch and continue the development. It will definitely be to our advantage if it is as readable as possible.