Thanks Andrew, Will work on it this week-end. Regards. Bharat
Joined: Jul 30, 2003
Hello Andrew, Follow-up question, you wrote:
For all those methods you mentioned - could anyone call them with an invalid record number (either outside of range or deleted)? If so, wouldn't you like to inform the user?
I had asked you these set of questions:
Also, I am not sure that I should be calling this [validateRecord(int recNo)] method from unlock and islocked methods? They both also throw RecordNotFoundException? For that matter, so do read, update, delete methods. I am a bit unsure of why Sun has those methods throwing RecordNotFoundExceptions?
Thinking through your answer, here is my analysis:
unlock and islocked methods - I don't think that these methods should have validateRecord private method call. My reasoning is that these methods should not be called by themselves by a programmer, rather, they should always be called with the method lock leading the way. For example, consider the business method "book" which resides in my DataAdapter class. The sequence of methods to be called in the data class is:
1. lock 2. read 3. update 4. unlock With lock method leading the way. Why should other methods validateRecord unnecessarily? lock method has already done that? Are you hinting that I should docoment this in my design documentation (choices.txt)?
read, update, delete - I can see that these methods can be called by themselves for different business requirements, therefore, I should call validateRecord method from within these three methods. Note that in the above scenario, i.e., book method. There is going to be a redundant repeation of this check in read and update methods.
Hi Bharat, I think a client could also call the isLocked() method (if you allow them to). Regardless, Sun have told you that unlock() and isLocked() should throw the RecordNotFoundException. You have a nice method that will verify that the record is valid, so why not use it for these two methods and fulfill Sun's requirements? Personally I agree that unlock() should not throw RecordNotFoundException. Since the lock had been granted, there should be no reason for the unlock not to work. And it will cause an exception to be thrown every time if you use the lock-delete-unlock sequence (does this mean that delete does an implicit unlock? or you just document this issue?). But my feelings are irelevant - Sun have told us what they want. Regards, Andrew
Hello Andrew, As suggested, I added the following three lines of code to the methods lock, unlock, islocked, read, update, delete.
Personally I agree that unlock() should not throw RecordNotFoundException. Since the lock had been granted, there should be no reason for the unlock not to work. And it will cause an exception to be thrown every time if you use the lock-delete-unlock sequence (does this mean that delete does an implicit unlock? or you just document this issue?). But my feelings are irelevant - Sun have told us what they want.
I find this rather alarming! Should we assume that Sun will be grading our submissions so much by the book? You are right, if we use lock - delete - unlock sequence, how will the unlock method not throw RecordNotFound exception? Will pointing this out in the documentation be enough? Note that I check two things in my validateRecord method: 1. That the record is within the range. I do that by doing on the spot computation of number of records in the file at that point in time. Therefore, should validateRecord method be synchronized? 2. That this is not a deleted record. Again, the same question. Another thing, should I keep persuing the exception handling (I am beginning to move on it, got side-tracked in getting the GUI piece going) here or would you and Max prefer to answer questions in the thread Hugh has started? Thanks for all your help thus far. You don't mind me answering questions on the forum which I can do you? I figure that takes a few off your shoulders. If you want me to follow a particular protocol while answering questions, feel free to point out. No offense will be taken. Regards. Bharat
author and jackaroo
if we use lock - delete - unlock sequence, how will the unlock method not throw RecordNotFound exception? Will pointing this out in the documentation be enough?
I think documenting this should be enough.
should validateRecord method be synchronized?
Hmmm - are you calling it from within synchronized methods? If so then you should be safe. If not, then you might want to synchronize it.
should I keep persuing the exception handling [...] here or would you and Max prefer to answer questions in the thread Hugh has started
Not really worried one way or the other. I guess this thread is getting a little long, so it might be easier to keep the Exception handling questions to Hugh's thread.
You don't mind me answering questions on the forum which I can do you?
Please, please, please keep answering questions. This forum does not belong to me, or Max, or any other contributor here. Your opinion is just as valuable as everyone elses, and just as welcome. I think people gain a lot answering questions - it helps concentrate the mind on why things work, and what the alternatives are. Regards, Andrew