I was looking at the usage of the ReadWriterLock class the Category code as an example for my similar modification to the PluginRegistry.
Shouldn't all the releaseWriteLock() and releaseReadLock() calls be contained in finally blocks? Unless we are absolutely sure that an exception cannot be thrown in that code, it seems like a good defensive coding style. Otherwise the lock counts could get out of whack at some point.
Hello Mark,
Constraining all lock operations to try/finally block is certainly safe. In the Category class where new ReaderWriterLock code was added, there is one occasion where a try/finally block is used, namely within the callAppenders method bacause the call to appendLoopOnAppenders can throw an exception upon appender failure.
However, in the other methods, lock operations are not constrained to a try/finally block because the probability of getting hit by an exception is extremely low.
Here is an example of what I mean
void incrementFoo() {
lock.getWriteLock();
foo++;
lock.releaseWriteLock();
}The above code is safe because if we cannot assume to be able to increment an integer variable safely, the situations is rather hopeless anyway. The following version is formally safer but only in theory.
void incrementFoo() {
try {
lock.getWriteLock();
foo++;
} finally {
lock.releaseWriteLock();
}
}By the same token, if we cannot assume to safely add an object to the array of vectors, than the situation is near hopeless, and all attempts at rescue are likely to be futile. That is why the other calls manipulating locks are not placed within a try/catch block.
I hope this answers the question,
-Mark
--
Ceki For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
