Lucas Theisen

Greenhorn
+ Follow
since Jan 16, 2008
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Lucas Theisen

Hi Alex,

Thanks for the reply. I agree that using RuntimeException (unchecked) is a possible solution. Do you think that is allowable given that Sun's stated purpose for Runtime exception is that it is for programming problems that your application cannot recover from (see the url from my original post). I am just thinking they might call that a bad design (though they really haven't left us any better option. Another thing I was thinking is that we could subclass RecordNotFoundException with something like NotLockOwnerException then it would get through. I dont think that is any less correct, because if you use a RuntimeException anybody that uses your api would have to know that they are possible and your method signature does not specify. Anyway, I think I agree with this approach more than the other 2 I mentioned previously, just wanted to know if I missed any other options.
Jose,

As I understand this, using name and location as a key might be a bad idea. Being that there is no room number column, if a specific hotel were to have multiple rooms available they would have the same name and location, but would truly be different entities.

All,

The way I read the requirements:

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



I think we should throw RecordNotFoundException in the case of no matches (even though I agree returning an empty array would be a much better design) because the "specified record" clearly "does not exist", so the exception "should" be thrown. If they wanted to be really mean, they could have a test case that does a find that has no matches, and if RNFE is not caught, display result[0] without checking the length of the array.
The DBMain interface that we "MUST" implement appears to be insufficient. It gives method signatures as follows:

public void update(int recNo, String[] data) throws RecordNotFoundException
public void lock(int recNo) throws RecordNotFoundException
public void unlock(int recNo) throws RecordNotFoundException

Along with the documentation on lock:

Locks a record so that it can only be updated or deleted by this client. If the specified record is already locked, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.

And a supplemental requirement:

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

Adhering to these requirements leads to the following issue. If lock/unlock/update do not return anything and only throw RecordNotFoundException (and RNFE is used as it "should" be), then how do you know if your call was successful? If a client ask for a lock that is already taken, it waits for the lock to be available before completing. However, if a client attempts to unlock or update and does not own the lock, the update will not happen, but there is no sufficient way to notify the client as to what happened. There are 3 ways around this that I can see:

1) Throw a RecordNotFoundException with a message stating "failed to update - not owner of lock".
2) Throw an unchecked exception.
3) Check to see if your update was successful by doing a read and comparing with what you just tried to update to.

All three of these have drawbacks:

1) RNFE has the stated purpose of being thrown when the "record does not exist or is marked as deleted", and the only way to know that this is what really happened would be to catch RNFE and check the message for this type of failure (HUGE HACK).
2) Unchecked exceptions have the stated purpose of "represent problems that are the result of a programming problem, and as such, the API client code cannot reasonably be expected to recover from them or to handle them in any way" (http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html) which is clearly not the case here.
3) Seems silly to have to check if your update actually went through by checking to see if the data is what you just tried to set it to.

Am I missing something here? Does anyone else have any ideas? As far as my client implementation goes, i would have the client remember if it was able to obtain the lock (by calling lock and waiting for it to return), but the fact that we have to implement this interface leads me to believe that other applications (such as the reporting applications mentioned in the overview) might need access to the data as specified. Any input/discussion would be greatly appreciated.