My specification for the above states the the Create routine should check for a DuplicateKey scenario. However the spec does NOT state what the primary key requirement is ? Is this left down to us ? Shouldn't the update method also check for this....it could be possible to update a record with the same field values as another....hence duplicate key.
Can anyone throw any light on what Sun's interpretation of this is supposed to be ?
I chose the same solution as Frans did. Not to throw the DuplicateKeyException at all. But, there is another possibility, and that is to define what u think is a key, note it in choices and make it a RuntimeException (that way, update can also throw it, because it needn't be declared), and throw it when necessary. Good luck
This another one of those topics that has been debated many times on this forum, and I just wanted to give you another view other than that presented.
Some people have decided to implement a primary key, and document what it is and why it was selected in their choices.txt. Personally I feel that keys should be used.
I have the B&S assignment, and I elected to make the name and location fields my primary key. Some people have made the entire record a primary key. Others have chosen not to implement it at all, and all appear to have passed. Whatever your decision, make sure you document it and you should be fine.
“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook