NX: createRecord and deleteRecord

[Jason Ford]

The createRecord and deleteRecord methods are prototyped in the DBAccess interface, but I am not required to provide these methods to the client. Some developers here have suggested that we should NOT provide implementations for these methods, because we are not required to do so by the specifications. Does this seem to be the prevailing opinion?
On a related note, my findByCriteria method calls a getRecords method that returns a list of all of the valid records in the file. It determines the number of possible records (n) in the file by computation, based on the size of the file, the size of the header, and the size of each record.
The getRecords method calls the readRecord method n times, once for each possible record. According to the specs, readRecord should throw a RecordNotFoundException if a record has its deleted flag set.
The situation look like this:

try {
    for (int i=0; i < NUM_RECORDS; i++) {
        String[] rec = readRecord(i);
        // Do something with rec
        ...
    }
} catch(RecordNotFoundException e) {
    // We expect to get here once for every deleted record
}

I'm still working on becoming better with exceptions. Is it ok to eat this exception?
Thanks,
Jason

[Mike Southgate]

IMO, yes. Just document in your code why you're eating it. ie "This just means we hit a deleted record that we want to skip anyway. Don't need to do anything" and you should be fine. There are exceptions to every rule, and this seems to be one IMO.
ms

[Mike Southgate]

Actually I just noticed an issue with your code. The try/catch needs to be INSIDE the for loop, or the first deleted rec you hit will exit the loop and you won't get the rest of the data.
ms

[Andrew Monkhouse]

Hi Jason

The createRecord and deleteRecord methods are prototyped in the DBAccess interface, but I am not required to provide these methods to the client. Some developers here have suggested that we should NOT provide implementations for these methods, because we are not required to do so by the specifications. Does this seem to be the prevailing opinion?

I think the prevailing attitude was that you have to provide implementations for create and delete in the Data class, but not use them in your client application.
Regards, Andrew

[Jason Ford]

Thanks for your responses. I will eat the exception and document it. I will also provide implementations for these methods. (I could hear Max saying: "If the Data class says that it can createRecord and deleteRecord, then it really should be able to do these things, even if nobody asks it to.")
Good eye, Mike. My actual code was written correctly, but the pseudocode I posted contained this subtle error. Thanks for pointing it out.
Thanks,
Jason

[Max Habibi]

Originally posted by Jason Ford:
Thanks for your responses. I will eat the exception and document it. I will also provide implementations for these methods. (I could hear Max saying: "If the Data class says that it can createRecord and deleteRecord, then it really should be able to do these things, even if nobody asks it to.")
Good eye, Mike. My actual code was written correctly, but the pseudocode I posted contained this subtle error. Thanks for pointing it out.
Thanks,
Jason

[David Chan]

I agree with Andrew to provide implementations for create and delete in the Data class but not use them.
Think about in practical situation, if this unclear requirements (some people said stupid) is given by customer but you just implement UnsupportedException in the createRecord and deleteRecord, will the customer satisfy with this? Should findByCriteria throw the same UnsupportedException if it got input param string[] with all non-null value? (sun only require to search record by hotel name and location). I think it is not reasonable to throw exception just because the GUI client does not provide these functionality.
At my point of view, the Data class is once all methods implemented and works fine, it seldomly need to be changed, so we need to implement it fully. AFAIK, adapter class can be changed over time to time if there are new functions to be added. Then, the adapter class contains find(String hotel, String location) and book(long recNo, String owner).
I believe sun want us to do this assignment in practical way.

David (Since Engish is not first lang, thanks for suffering from reading this msg)

[Javini Javono]

Hi,
Concerning the reference above to "eating exceptions."
Here are my ideas, but keep in mind that my design ideas for the Data class is,
perhaps, significantly different than the majority.
Certainly I find the Data class and the interface it implements weird and
restrictive. I've tried a few tricks, but my new idea, which I have not yet
implemented will be this:
DataFace will have as a component Data. Anyone who wants to talk
to Data has to go through DataFace. Data will have associated with
it an object which holds any type of exception Data might get. DataFace
will share this object with Data. Data will not necessarily through any
exceptions, but if any are encountered, the exceptions object will
be set accordingly to that DataFace knows about it. DataFace will in
turn throw any type of reasonable exception, just as if Data restricted
Java interface never existed. In this way, no exceptions are ever eaten.
Thanks,
Javini Javono