Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

DuplicateKeyException

 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,
I have to implement the following method for my Data Class.



I am not able to understand in which scenario will i get the DuplicateKeyException? The method does not take a parameter for the Record Number so it is obvious that we need to find the Record Number( Return Value). In that case then we can always be sure to generate a Number that is not duplicate.
please can someone tell me if there is a possibility of getting duplicate Keys?
Thanks in Advance,
[ May 01, 2006: Message edited by: Barry Gaunt ]
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
create RETURNS the record number it created.

It generates a new record, so the record number should not yet exist, create must itself make sure of that.

The DuplicateKeyException would theoretically be thrown when the record key already existed in the database and the database didn't allow for duplicate keys.
In practice (at least in this database) no key is defined so no duplicate key can ever exist.
So in practice the exception won't ever be thrown.
 
Sam Codean
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. That makes it clear
 
Joe Murphy
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could the DuplicateKeyException thrown by this method be used to propagate a different type of exception up to the client?
For instance, an IOException encountered when attempting to write to db file could be caught and then thrown as PuplicateKeyException (since this is the only type of exception defined in the method signature?)
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMO abusing an exception to do something different is very poor design.
Were I a grader for Sun I'd subtract serious points for such a decision (note, I'm not. I've just been working on my assignment for the last 10 months and might be starting to think like one).

Instead what I've done as the next best thing is design a RuntimeException (which I called DatabaseException) which is passed instead to hold generic errors and wrap other exceptions.
Not the best thing, but there's really no other way.

Of course many of the methods in the database interface return something you could use to indicate failure instead.
A boolean result of false could indicate failure (but then, what failure would it be?).
An object reference could be set to null to indicate failure (again, no indication of what the failure actually was).
 
Joe Murphy
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My only problem with using a runtime exception is that runtime exceptions generally serve to indicate a programmatic error from which a caller cannot normally recover.
The runtime exception is not a checked exception, so there is no indication to other clients of this method that the method may throw this exception (until runtime that is) - whereas there is a checked exception available.
Using the existng checked exception type, whilst inappropriately named indicates to the programmer re-using the method that there is an exceptional condition from which they may recover.
I completely agree neither are ideal by any means but since this is the interface supplied, I would be really interested in others thoughts as to this? What have others done in this situation? What is the best approach!
 
Joe Murphy
Greenhorn
Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just found quite lengthy & useful discussion on this topic here:

http://www.coderanch.com/t/183822/java-developer-SCJD/certification/NX-Exception-handling-implementing-DBAccess

I haven't come to any firm conclusions though ;-)
 
Thirumurugan Mylrajan
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just an opinion..

For the URLYbird app, we are developing an application which enables booking of hotels.

Should we allow multiple records for the same hotel in the same place, same room in the Hotel.

You can very well get the key here. Just have to document the assumptions.
 
Jeroen T Wenting
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Same room should be no problem. Same room at the same time would be problematical.
But that's business logic, not database logic.

Duplicate Key hints at there being a key to the table, but the assignment documentation (at least mine, and others seem to have the same) doesn't mention any key so you have to assume there is none.

A DuplicateKeyException would be thrown when trying to insert a record with an identical set of key fields to an existing record, but with no key on the table it will never be thrown as there will never be a duplicate key.

Another database implementing the same interface though may have a key attached to it, so there is a reason to have the throws clause in there (since you can't add throws clauses in implementing classes or children).
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic