Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Swallowing an InterruptedException?

 
Rob van Oostveen
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 961
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 38
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic