Win a copy of The Business Blockchain this week in the Cloud forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Exception to throw when unlocking a record that is not locked

 
Olu Shiyan
Ranch Hand
Posts: 57
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have read the discussion here about not throwing RecordNotFoundException from the method and it makes sense.

So firstly, what I've done is to throw a SecurityException if the record number specified is indeed locked and the cookie doesn't match that which was used to lock the record.

Secondly, if the record number specified does not exist in the 'lockedRecords' Map (meaning its not a locked record), I also throw a SecurityException with a message that tells the user that: 'You must first lock a record before you can unlock it.' Of course my lock() method throws RNFE as appropariate.

However, I'm wondering whether this second part is necessary or whether a SecurityException is the appropriate exception to throw if a user specifies a record number that is not locked (as described above)?


Suggestions? Confirmations? Criticisms?

Thanks
Olu

[Edit: changing subject line to make more sense]
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, Olu!

Secondly, if the record number specified does not exist in the 'lockedRecords' Map (meaning its not a locked record), I also throw a SecurityException with a message that tells the user that: 'You must first lock a record before you can unlock it.' Of course my lock() method throws RNFE as appropariate.


Well champ, I'd say that a more appropriate exception to be thrown in this case would be the IllegalStateException, because someone is trying to unlock a record whose number should be in your lockedRecords map, and it isn't, so it is in a illegal state. If I make no mistake, my good buddy Roel also took this approach.
 
Olu Shiyan
Ranch Hand
Posts: 57
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks! Roberto
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Olu,

I think it depends on the method signatures in your interface. If I'm not mistaken there are some version where update/delete/unlock methods have a "throws SecurityException" clause. So in this case I would throw a SecurityException. My interface didn't have such method signatures, so I opted to simply throw an IllegalStateException.

Kind regards,
Roel
 
Olu Shiyan
Ranch Hand
Posts: 57
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi Roel,

The unlock() method in the Sun interface I received throws SecurityException which is why I initially coded it like I explained in my first post. I think the scenario of invoking the unlock method with a record number that's not locked is some kind of Security Exception too. However, Roberto's explanation about the Map seems to make sense as well. Now Im slightly confused about which one to choose?

Another thing is the InterruptedException which can be thrown from the invocation of wait() in the lock method. At present I've rethrown it as a RuntimeException but I wonder whether that's the right thing to do?


Cheers
Olu
 
Carlos Morillo
Ranch Hand
Posts: 221
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Olu,

I do what my interface says:



Please try to use the search engine of the SCJD forum. Many of these questions have already been answered.
Look here regarding InterruptedException in the lock() method.


HTH,


Carlos.
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, Olu!

Well, for the original question, I'd say that it would be more appropriate to throw IllegalStateException because the object would then be in a illegal state. The SecurityException would be more appropriate in a case, say, where client A locks record 1 and client B tries to unlock record 1. In other words, where the record is locked, but the cookie received does not match the one that was assigned to the client who originally locked the record. But, if you choose to throw SecurityException in this case, you can mention it in your choices.txt file and say that in your point of view, trying to unlock a record that was not locked is a security violation.

For the second question, I'd say that a good way out would be to wrap the InterruptedException in a RuntimeException.
 
Olu Shiyan
Ranch Hand
Posts: 57
Java Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Thanks guys for the responses.

Roberto I think you are right about IllegalStateException being more appropriate for the above mentioned scenario. However, for this assignment, to be on the safe side, I think I'll just throw a SecurityException since it's in the method declartion, although throwing an IllegalStateException won't hurt since it's a RuntimeException subclass.

Carlos: Yes I did read that thread related to InterruptedException, thanks. I probably shouldn't have asked the same question. As for the question about the InterruptedException, I currently have it wrapped with a RuntimeException and rethrown. I think this will do.


Thanks
Olu
 
Carlos Morillo
Ranch Hand
Posts: 221
Java Python Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In my personal opinion it is more elegant and cleaner when a thread calls the lock() method
and is waiting in a loop while the record is locked and it catches an InterruptedException to restore the
interrupted status to not swallow the interrupt, as illustrated in the
book "Java Concurrency in Practice" by Brian Goetz Chapter 5 Section 5.4 Listing
5.10 and in http://www.ibm.com/developerworks/java/library/j-jtp05236.html.


HTH,


Carlos.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic