*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Question about InterruptedException  in lock method 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 "Question about InterruptedException  in lock method" Watch "Question about InterruptedException  in lock method" New topic
Author

Question about InterruptedException in lock method

Olena Golub
Ranch Hand

Joined: Jan 17, 2005
Posts: 113
Hello Everyone,

my locking method contains the following code:


What is the best way to handle this exception? 1. Throw the exception or 2. just write it to Logger?

My book method from the business layer looks like:


Could you help me?
Thanks a lot for your help!!!
Olena.


SCJP 1.4<br />SCJD 1.4 (in progress)
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24


Definitely don't throw the exception. In fact your best bet is probably to catch it and then just ignore it. As far as I can tell, the only way to generate this is exception is to call Thread.interrupt(), and the JVM itself will never call this method.

In my opinion, InterruptedException should never have been a checked exception.
[ May 18, 2005: Message edited by: Titus Barik ]
Anatoly Stanislav
Greenhorn

Joined: May 18, 2005
Posts: 1
I did quite opposite in my assigment (I have not submitted it yet!)


Yes, I agree, InterruptedException should never be thrown issued by JVM.But what if JMV will be changed in the future? In my case users will get an exception and can try to book a record again. If exception is swallowed and program continued, database could be corrupted.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11432
    
  85

As mentioned in other topics, a method called from a remote client will continue to run, even after the client has disconnected. Given this fact, if a client disconnects, you might choose to have your server code interrupt any threads that are currently waiting for locks.

So it could be your code that is causing the interrupt!

(Not that I am suggesting that you do this, just letting you know of one potential way interrupts could occur – if this were a real life project, sometime in the future the server could be "enhanced" in this way).

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
Originally posted by Anatoly Stanislav:
I did quite opposite in my assigment (I have not submitted it yet!)



I like your implementation! Wrapping the exception in a RecordNotFoundExceptioin is not a bad idea at all.
Olena Golub
Ranch Hand

Joined: Jan 17, 2005
Posts: 113
Hello All,

After reading some topics about this problem I decided to implement it in this way. But I am not sure if this is correct. Could you please say your opinion?

To make it more clearly I will divide my code in three parts:

1. The first part is Data access, represented by Data.
2. The second - the business tier, represented (e.g. for standalone) by DataAdaptor, that is the wrapper for Data.
3. Third is the GUI tier, represented by DataModel, that is a part of MVC.

The communication between this parts works in this direction:
{DataModel}.bookRecord(..) ---> { DataAdaptor }.book(..) --> {Data}.lock(..)

I defined two exceptions LockException and RecordNotBookableException that extend the RuntimeException.

In Data lock(..) I have following:



In DataAdaptor I reimplemented the book(..) method:



I don�t catch here the RecordNotFoundException and SecurityException exceptions that can occur also during the booking process. These exceptions I catch in Model.

And the in the Model I defined this code:

How do you think about this idea?

Thanks a lot for your comments!
With kind regards,
Olena
[ May 19, 2005: Message edited by: Olena Golub ]
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Olena,

forgive me , but I don't like your exception handling in case of InterruptedException. Why not simply ignoring it as Titus said?

From a user perspective I can't see any benefit from all your exception messages. A user does not care on threads or locks.

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
Originally posted by Darya Akbari:

From a user perspective I can't see any benefit from all your exception messages. A user does not care on threads or locks.


Perhaps not with that particular message, but I imagine one could simply say RecordNotFoundException: "An internal error occurred preventing the record from being accessed." or something to that effect.
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
What speaks against ignoring the InterruptedException?

Regards,
Darya
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
I found something that speaks against it :

As it is mentioned in the SCJD part of K&B:


Never, Ever, Ever Eat an Exception
By eat we mean the following horrible practice:



See what’s missing? By catching the exception and then not handling it in any way, it goes completely unnoticed, as if it never occurred. You should at the least print the stack trace. Putting something like this in your exam project might be the death blow.



Regards,
Darya
Titus Barik
Greenhorn

Joined: May 15, 2005
Posts: 24
Originally posted by Darya Akbari:
What speaks against ignoring the InterruptedException?


Interruped Exception is Checked speaks against it, "The general problem is that Java has some bad choices about which exception classes should be checked. That is, there are a lot of exception classes which ought to be subclasses of RuntimeException, but in fact are not."
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
I agree, "eating" the exception is not the right thing to do and will probably result in bad impression in the eyes of the reviewer or unnecessarily lost points.

Another alternative to dealing with this situation is wrapping the checked exception in an unchecked one that is not caught by any code. Since this is a remote possibilty that can be interpreted as "low level system failure", this behaviour would be appropriate.

I believe throwing an uncaught runtime will translate to a RemoteException being thrown on the method invocation, which your RMI client code could handle.

Hope this helps.


Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Do you all agree that at least one should do a printStackTrace()?

Especially when it comes to provide the user with some meaningful exceptions wrapped in a JOptionPane and on the other hand to use printStackTrace() for some exceptions that should not reach a user.


Regards,
Darya
Reza Rahman
author
Ranch Hand

Joined: Feb 01, 2005
Posts: 580
    
    5
Darya:

It also wouldn't be too much more work to just log the exception in some kind of persistent storage (e.g. using the java logging API). In my case, I log all exceptions and show the user abstracted "watered down" messages.

Reza
 
Consider Paul's rocket mass heater.
 
subject: Question about InterruptedException in lock method