Check Dont Catch

It is often more efficient in Java to check to see if an exceptional condition exists than to let an exception be raised and have to catch it afterwards.

For example, a loop such as this

   try {
     for (int i=0; ; i++) {
       // do something with someArray here
     }
   } catch (ArrayIndexOutOfBoundsException ex) {
     // ignore the exception
   }

   for (int i=0; i < someArray.length; i++) {
     // do something with someArray here
   }

(Actually, for large lists the first method may well be faster - have tested this - since you're is doing the in-bounds check and you're not replicating it. The overhead of the exception throw is outweighed by the time saving for each iteration. But it's VERY BAD!)

Instead of null as return value use the NullObject pattern, or if you can't do so throw a RuntimeException. If you throw an exception you should provide a possibility to check if the critical method can be executed without causing an exception. Hence..

	try {
		obj.get(foo);
	}
	catch (RuntimeException e) { ... }

	if (obj.contains(foo)) {
		// we are now sure that get(foo) doesn't throw an exception
		obj.get(foo);
	}

The above is copied from NoNullBeyondMethodScope.

It is my understanding that contains() in almost any collection class is usually only slightly faster than get(). So the second example is essentially calling get() twice. Is a try catch block so time cost prohibitive that calling get() twice is still faster?

Also, if a particular collection implementation has already synchronized get() then locking on obj before contains() and releasing after get() will double lock obj, a situation which I was under the impression one should avoid when possible. If the collection is not ThreadSafe then even if you lock obj, the remove() method will not be synchronized and contains() could return true and get() could result in an exception. It is probably unlikely, but it is not still possible? So then to be really sure you won't get a NullPointerException you'd have to lock obj every time you try to access it. And to cover the double lock case mentioned above, you should probably introduce a new object and lock on that instead.

The following 4 cases were tested in Java 1.5.

	The naive, just get() it and let a NullPointerException generate a stack trace
	The try-catch block around get()
	The unsynchronized contains() then get()
	The synchronized constains() then get()

The results were in the listed order from fastest to slowest for a million element HashMap. Surprisingly enough they were in the same order for a thousand element HashMap, and in fact were the same even for a 10 element HashMap.

So if try-catch is faster, and it avoids the unnecessary complications and potential pitfalls of the contains() then get() route, is it not wiser to CatchDontCheck instead of CheckDontCatch?

Try-catch indicates that we are about to try something that might not work, if indicates that we have a condition that must be met before we will do something. For the particular example from NoNullBeyondMethodScope, doesn't try-catch capture the intention of our code better than the contains() then get()?

These are serious questions, not meant to be rhetorical. If I can convince the Wiki, then I might try convincing my co-workers.

--MikeDoberenz?

CategoryException

This page mirrored in JavaIdioms as of April 29, 2006