• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: createRecord and deleteRecord

 
Jason Ford
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

I'm still working on becoming better with exceptions. Is it ok to eat this exception?
Thanks,
Jason
 
Mike Southgate
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author and jackaroo
Marshal Commander
Pie
Posts: 11914
209
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic