• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

lock-delete-unlock and RecordNotFoundException

 
Jared Chapman
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Consider the method in the DB interface provided by Sun:

and the program requirements provided by sun:

My instincts tell me that, in this case, I should interperate this requirement (about when to throw RNFEx) as:
"...should do so if a specified record does not exist, AND go ahead and do so in any other appropriate cases where you are looking for a record (or its representative) and cannot find it, since we didn't explicitly state in the requirements that you MUST ONLY do it if the record does not exist or is marked as deleted."


In the unlock method, I am considering the representative of a record to be its record number. If I attempt to unlock record #5, but record #5 is not locked, then I will not be able to find it among the locked records, and therefore should throw a RecordNotFoundException.

At least this way you can provide the information that an attempt was made to unlock a record that was never locked, and possibly track down a breach of the lock(recNo)- modify(recNo)- unlock(recNo) contract.

Any thoughts?
[ November 02, 2004: Message edited by: Jared Chapman ]
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

I am against it.

When someone tries to unlock a record that has not been locked before it is a programming error; it shall not be possible by a misuse of the program by the user. It is always avoidable and should be avoided rather than recovered. Thus the Exception should be a RuntimeException.

I suggest a "LockException extends RuntimeException".

Conan
 
Jared Chapman
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, and thanks for your response.

I agree, it is a programming error and should therefore throw a runtime exception, if any. Good point.

RecordNotFoundException is indeed a meaningless exception in the unlock method. After all, unlock doesn't know if it's being called after a create or delete - one is supposed to find a record and one isn't.

So let me make sure I understand your suggestion correctly:

If a user tries to perform a data-altering method, like without locking the record first, one of two things will happen:
1. recNo is in lockedRecords, but the made up long value will not match the long value used to lock the record, and a SecurityException should be thrown.
2. recNo isn't in lockedRecords, meaning the record was never locked (programming error), so a runtime exception should be thrown.

Or, if a user tries to unlock a record without locking it first (using recNo and some made-up value), the same two things can happen, and should be handled the same.

So this LockException you suggest (which is a runtime exception) will be thrown from update, delete, and unlock, if the record isn't locked.

Correct?
 
Kai Witte
Ranch Hand
Posts: 356
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hello,

Originally posted by Jared Chapman:

If a user tries to perform a data-altering method, like without locking the record first, one of two things will happen:
1. recNo is in lockedRecords, but the made up long value will not match the long value used to lock the record, and a SecurityException should be thrown.
2. recNo isn't in lockedRecords, meaning the record was never locked (programming error), so a runtime exception should be thrown.

Or, if a user tries to unlock a record without locking it first (using recNo and some made-up value), the same two things can happen, and should be handled the same.

So this LockException you suggest (which is a runtime exception) will be thrown from update, delete, and unlock, if the record isn't locked.

Correct?


I recommend a LockException for all cases you mentioned: Any kind of violation of the "lock contract". Here is a part of my choices.txt in which I described a part of the "lock contract":

-The methods update and delete require a lock, and only those.
-To call a method which requires a lock clients must call the lock
method first and wait for it to return.

(ommited some parts, for example about when unlock must be called)
Using the same kind of RuntimeException for all violations of the lock contract makes it simpler. I find it hard to justify to distinguish between different kinds of lock contract violations by using different exception classes.

I had B & S 2.3.2, which has no cookie, so I didn't think about your concrete case as much as you did, though.

Conan
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic