An unlock method that doesn't throw RecordNotFoundException

[Mogens Nidding]

Here is question that seems to be about locking, but is really about exceptions and "design by contract":

Assume that the lock method only lets the client lock valid (non-deleted) records. Also assume that the unlock method throws an IllegalStateException if a client tries to unlock a record that he does not own the lock on.

Due to these constraints, which I found very reasonable to add, it is impossible for a RecordNotFoundException to be thrown from the unlock method, even though the instructions clearly stipulate that

Any methods that throw RecordNotFoundException should do so if a specified record does not exist or is marked as deleted in the database file. (my emphasis)

How do I stand on scoring on this issue? To be on the safe side, I guess I should check for the existence of the record before I do anything else, don't you think? Or is this one of the things that, given a bit of documentation, are totally OK?

[Mike Vess]

I have removed "throws RecordNotFoundException" from my unlock method and i have written down why in my choices document. I think this is okey because if you call lock, delete and then unlock it will almost always throw a RecordNotFoundException if not another thread has called create and reused old record before thread one calls unlock.

[Mogens Nidding]

But if unlock() almost always throws RecordNotFoundException, how can you remove it from your unlock method?

Just to clarify, I assume you are talking about this interesting scenario:

1. Client A locks record 007

2. Client A deletes record 007

3. Client A unlocks record 007 --> RecordNotFoundException because 007 is deleted

Are not NOT throwing RecordNotFoundException in step 3? This would make sense if we assume that delete() will automatically release the lock, and then throw InvalidStateException in unlock() instead.

[peter wooster]

Originally posted by Nicky Bodentien:
But if unlock() almost always throws RecordNotFoundException, how can you remove it from your unlock method?

Just to clarify, I assume you are talking about this interesting scenario:

1. Client A locks record 007

2. Client A deletes record 007

3. Client A unlocks record 007 --> RecordNotFoundException because 007 is deleted

Are not NOT throwing RecordNotFoundException in step 3? This would make sense if we assume that delete() will automatically release the lock, and then throw InvalidStateException in unlock() instead.

I agree and have taken the approach that delete unlocks the deleted record. Once the record is deleted, its no longer available in its old form. It could appear as a new record added by the create method, which doesn't check locks, so it makes no sense to let it remain locked.

An attempt to unlock the deleted record will throw RecordNotfoundException if the record hasn't been reused, and SecurityException if it has been reused. I assume that the SecurityException defined in UyB is the same as your InvalidStateException.

[Anton Golovin]

Originally posted by Nicky Bodentien:
But if unlock() almost always throws RecordNotFoundException, how can you remove it from your unlock method?

Just to clarify, I assume you are talking about this interesting scenario:

1. Client A locks record 007

2. Client A deletes record 007

3. Client A unlocks record 007 --> RecordNotFoundException because 007 is deleted

Are not NOT throwing RecordNotFoundException in step 3? This would make sense if we assume that delete() will automatically release the lock, and then throw InvalidStateException in unlock() instead.

If you implement the RecordNotFoundException, it would be with this check:

if(record is not locked and (&) record is deleted) then throw RecorcNotFoundException

[Anton Golovin]

Originally posted by peter wooster:

I agree and have taken the approach that delete unlocks the deleted record. Once the record is deleted, its no longer available in its old form. It could appear as a new record added by the create method, which doesn't check locks, so it makes no sense to let it remain locked.

An attempt to unlock the deleted record will throw RecordNotfoundException if the record hasn't been reused, and SecurityException if it has been reused. I assume that the SecurityException defined in UyB is the same as your InvalidStateException.

THe create method is quite an interesting one. It must check locks, and once it checks locks, it also must check that the record it is about to overwrite is still deleted. If anyone is interested, I will post my version of the create method.

[Mike Vess]

But if unlock() almost always throws RecordNotFoundException, how can you remove it from your unlock method?

My easy solution is to NOT check that the record exists or not in unlock method, i just remove the record number from my table of locked records.

[Paul Bourdeaux]

I have B&S 2.2.3 and my interface does not throw the RecordNotFoundException in the unlock method - only the SecurityException if the incorrect cookie value is passed. I am assuming that this is one of the differences between the versions of the assignments.

If you implement the RecordNotFoundException, it would be with this check:

if(record is not locked and (&) record is deleted) then throw RecordNotFoundException

This would solve the problem of throwing the exception after a delete, but this may not work for all cases. If a client tried to unlock a record that has never existed the exception would not be thrown.

 
if(record is not locked and (&) record is deleted)
            TRUE                      FALSE         = FALSE

Please correct me if I am incorrect with this.
[ October 06, 2004: Message edited by: Paul Bourdeaux ]