A Java bounds-checking optimization example

I have read that some of the JVMs out there can optimize code execution by removing bounds checking. What I am trying to figure out is what coding technique will work better.

In method example1 below would the JVM ever figure it out and eliminate the bounds checking of the source[index] reference?

Is example2 the better code practice? It would seem so, but in some algorithms inside a loop 开发者_高级运维the index being out of bounds is a normal condition. So you don't want to be generating tons of Exception objects inside that loop.

public void example1(int [] source, int index) {
    if (index >= 0 && index < source.length)
        System.out.println("Value is " + source[index]);
    else 
        System.out.println("Out of range: " + index);
}

public void example2(int [] source, int index) {
    try {        
        System.out.println("Value is " + source[index]);        
    } catch (IndexOutOfBoundsException exp) {
        System.out.println("Out of range: " + index);
    }
}

These code fragments are only representational. I am aware that in these examples the bounds-checking will hardly matter to performance. However I am working on an embedded protocol application where the redundant bounds checking will add up.

To your first question, in example1 the bounds check can theoretically be eliminated. I'd expect the best modern JIT compilers to do this (e.g. perhaps via common sub-expression elimination in the bounds check when source[index] is expanded). As usual this will be implementation dependent so you can't rely on it. OTOH even if the bounds check isn't eliminated the difference will be trivial - you're hitting the already cached memory location for source.length and doing a couple of integer compares so the overhead is tiny.

example2 is not good practice - you are hitting an exception but then catching it and continuing as if nothing happened. Unless you are watching stdout closely you might completely miss the fact that there is a bug in your code.

There are basically two common "good" possibilities depending on what you consider to be a valid input for "index":

1. An out-of-bounds index value is expected and is considered valid input. In which case you should test and handle it explicitly as in example1. You shouldn't need to throw any sort of exception in this case.

2. An out-of-bounds index is unexpected (and is therefore a bug in the calling code). Your code should raise an exception here. If you like you can catch and re-throw the exception with your own message but you could also just let the IndexOutOfBounds exception propagate. Don't worry about the performance impact of this exception handling - you have just discovered a bug and therefore you want the program to fail as quickly and "loudly" as it can.....

I don't see how the index being out of bounds could ever be a normal condition. Either your algorithm has a bug, or you don't validate input correctly. And validating input, in this case, consists in checking that the index is in the bounds. Checking it with an if (as in your first snippet) is obviously much more readable, clean and efficient than catching an exception.