• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Swallowing an InterruptedException?

 
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 961
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Politics n. Poly "many" + ticks "blood sucking insects". Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic