Exception to throw when unlocking a record that is not locked

[Olu Shiyan]

I have read the discussion here about not throwing RecordNotFoundException from the

public void unlock(int recNo,long cookie) ...

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]

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]

Thanks! Roberto

[Roel De Nijs]

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]

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]

Hi Olu,

I do what my interface says:

    /**
     * Releases the lock on a record. Cookie must be the cookie returned when
     * the record was locked; otherwise throws SecurityException.
     * 
     * @param recNo
     *            an <code>int</code> containing the number of the record to be
     *            unlocked.
     * @param cookie
     *            a <code>long</code> value is a cookie which must be the cookie
     *            returned when the record was locked.
     * @throws RecordNotFoundException
     *             when the record does not exist.
     * @throws SecurityException
     *             if the record is locked with a cookie other than lockCookie.
     */
    public void unlock(int recNo, long cookie) throws RecordNotFoundException,
            SecurityException;

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]

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]

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]

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.