How would we use try finally for Lock.lock and Lock.unlock

Question

Consider the following code. In order to prevent IndexOutOfBoundsException while calling listIterator, we use a reader lock to retrieve the index based iteartor, and writer lock else where when write operation on stockCodes.

Take note that, we didn't use any locking mechanism to iterate using listIterator, as it is from CopyOnWriteArrayList. Locking is not required as ConcurrentModificationException shall not be thrown.

// stockCodesReaderLock is reader lock from java.util.concurrent.locks.ReadWriteLock
// stockCodes is CopyOnWriteArrayList
// Acquire iterator in a safe way.
stockCodesReaderLock.lock();
final int stockCodesSize = stockCodes.size();
if (currIndex < stockCodesSize) {
    listIterator = stockCodes.listIterator(currIndex);
}
stockCodesReaderLock.unlock();

I was wondering, whether I should have try/finally block, as I cannot see any chance for exception to arise? If using try/finally is a must, should I use (A) or (B)?

Is there any need for me?

(A)

try {
    stockCodesReaderLock.lock();
    final int stockCodesSize = stockCodes.size();
    if (currIndex < stockCodesSize) {
        listIterator = stockCodes.listIterator(currIndex);
    }
} finally {
    stockCodesReaderLock.unlock();
}

---

(B)

stockCodesReaderLock.lock();
try  {
    final int stockCodesSize = stockCodes.size();
    if (currIndex < stockCodesSize) {
        listIterator = stockCodes.listIterator(currIndex);
    }
} finally {
    stockCodesReaderLock.unlock();
}

Answer 1

The other respondents are right: you should always use try/finally.

Regarding whether (A) or (B) is correct, Sun seems to recommend (B) in the JavaDoc of ReentrantReadWriteLock (search for "finally" to see it). I suppose this is because the lock() method could throw an exception if it fails: for example, the JavaDoc says it will throw an Error in the obscure case where the same thread attempts to acquire the lock recursively more than 65535 times.

Answer 2

It's good defensive programming. If your code ever changes so that the body throws an exception for any reason whatsoever (including, for example, OutOfMemoryError), you'll be glad you didn't leave the lock in a stuck state.

I'd personally go for (B) - if the lock() method itself were to throw an exception, it would still be balanced. But in practice I don't think it matters that much.