My create method does not throw a DuplicateKeyException as it assigns new record number inside the create method and it does not enforce any primary key on the records fields. I know alot of people have taken this approach and just left the method signature as is and documented in their choices.txt.
For my update/delete and unlock methods i have overriden the signatures that were supplied in the DB interface due to issues i see as violations in how the API is used. So for example i have removed the RecordNotFoundException from the unlock method as it is possible that a thread who has the lock on a record may delete it.
Is there a case to do the same for the create method and override its signature so that it does not throw the DuplicateKeyException? The only issue i can see with this is that maybe in the future if the underlying database is changed then this method may need to throw that exception. Any thoughts? Thanks
Colin Duggan wrote:The only issue i can see with this is that maybe in the future if the underlying database is changed then this method may need to throw that exception. Any thoughts?
And that's exactly the reason why I would not override this method. With update/delete/unlock methods it makes sense, because this exception will never be thrown from these methods. That's not guaranteed with the create-method. Just my 2 cents.
I just registered for the exam last week, and did a little bit of work on past weekends. I was reading this forum to see how people solved their problem and I'm not quite sure why you shouldn't throw DuplicateKeyException? I wrote a unittest where I'm trying to add two valid records which have same name and specialties and test should expect DuplicateKeyException be thrown. If I understand task correct, we should enforce entity integrity by checking, if combination of fields which creates primary key already exist in database. So we have to prevent adding records with same primary keys. It's not a rocket science to do, and it makes perfect sense for me. Am I missing something?