Meaningless Drivel is fun!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Swallowing an InterruptedException? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Swallowing an InterruptedException?" Watch "Swallowing an InterruptedException?" New topic
Author

Swallowing an InterruptedException?

Rob van Oostveen
Greenhorn

Joined: Aug 14, 2006
Posts: 21
Hi,

I was wondering how you handle the InterruptedException while waiting for an object using the wait() method. For instance;



The above code sample shows a wait() call on a lockedRecords object and whenever a notifyAll() is called by another trhead the while loop checks to see if the record is still locked. But what should I do whenever the wait() method is interrupted? It is considered bad practice if an InterruptedException is swallowed..

Any comment is welcome.

Thank you.

Regards,
Rob
[ September 21, 2006: Message edited by: Rob van Oostveen ]
Edwin Dalorzo
Ranch Hand

Joined: Dec 31, 2004
Posts: 961
Due to the restrictions in the method signature stated by the Sun spec I am throwing a RecordNotFoundException if the lockRecord is interrupted while waiting for a record lock.

This is compliant with the method signature and after all I was not able to get the lock on the record, therefore it does not sound so bad to throw a RecordNotFoundException.

I have been also thinking of possibility of specializing RecordNotFoundExceptions into more specific exceptions. But I have to think this carefully.
Robert Bar
Ranch Hand

Joined: Jun 29, 2006
Posts: 38
Hi Rob,

Think about consequences of swallowing that exception: lock() returns normally, and client modifies the record without the lock! Another client can lock the same record at the same time.

Generally, you should either complete your contract and return a valid result, or throw an exception. It's a samurai principle : Return victorious, or not at all.

Consider also throwing some kind of runtime exception. RecordNotFoundException signals that record doesn't exist, and maybe it would be better to rest the meaning of that exception unchanged. What do you think about that?

regards,
Robert
Rob van Oostveen
Greenhorn

Joined: Aug 14, 2006
Posts: 21
Hi Robert,

Thank you for your reply. So you're saying that I should throw RecordNotFoundException in case this happenes? I don't have much choice though, because I'm stuck with the Interface contract. The sample code exists in the lockRecord method which is declared in the Interface as follows:



Another way of dealing with this is by reinterrupt the thread. So the interrupt status can be learned by other code up the stack. This way I don't do nothing. It looks like this:



The downside to this, I think, is the code will continue executing after the reinterrupt so it might get dangerous in terms of thread-safety, like you described.

My thought is to throw the RecordNotFoundException and describe the choice in the choices.txt. Personally I don't like the solution, but sometimes we do things in life only to fulfill contracts..

If you have another suggestion, please let me know.

Regards,
Rob
Rob van Oostveen
Greenhorn

Joined: Aug 14, 2006
Posts: 21
One other thing to do is reinstate the interrupt status and throw InterruptedException. Like this;



Just another thought..

Cheers,
Rob
[ September 22, 2006: Message edited by: Rob van Oostveen ]
Daniel Massie
Greenhorn

Joined: Jan 08, 2005
Posts: 28
I handled the interupt scenario by allowing a number of attempts at locking and when the maximum number has been reached a runtime exception is thrown which wraps the original exception. The runtime exception is thrown from the data class whenever an unrecoverable exception is thrown such as IO or an interrupt. These exceptions can't be rethrown as a RecordNotFoundException as that has a specified cause thus making the runtime exception the best option.
Robert Bar
Ranch Hand

Joined: Jun 29, 2006
Posts: 38
Hi,

Originally posted by Rob van Oostveen:
Hi Robert,

Thank you for your reply. So you're saying that I should throw RecordNotFoundException in case this happenes? I don't have much choice though, because I'm stuck with the Interface contract.

If you have another suggestion, please let me know.

Regards,
Rob


No, no, no. Please read my first post again, I suggest to use runtime exception.
As I wrote before, RecordNotFoundException has unambiguous interpretation: it should be thrown if record doesn't exist or is marked as deleted. In any other situation I suggest to utilize subclass of RuntimeException, cause it don't change the required interface, and don't overload the meaning of RecordNotFoundException.

At last, throwing RecordNotFoundException is much more acceptable than eating the exception.

Just don't sweep dirt under the carpet. ))

regards,
Robert
 
Don't get me started about those stupid light bulbs.
 
subject: Swallowing an InterruptedException?