• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: DuplicateKeyException for records without keys!? *blink*

 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My project database Interface (the one the make you use) seems to use record number as its key, and as there is no record number in the schema I am assuming this is basically the order it comes in the file. If this is true how can the add() method possibly ever have a duplicate key?
Unless I am supposed to be simply checking that Name and Location together are a unique pair?
But then all the exception handling that is insisted for this project seems odd. RecordNotFoundException on the find() method?! Err.... duh!
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, while there is some less than desired desing choices, there is still a basic database logic that is in there for those two exceptions you are toalking about. I think the idea that record number is the actual number in order in the file, and a primary key, there is always this confusion. a Primary key can also be a "unique" key, like you have pointed out. So the DuplicateKeyException in the add method is very logical. If you pass a record that has the same name and location that already exists in the database, then you should not add it, it should throw the exception. Just like a unique constraint in Oracle or SQL Server would throw an error.
Now the find method could throw a RecordNotFound error in the case of a record number that has been deleted. So client A searches and find 3 records, record #1, 2, 3. Client B deletes record #2, then client A selects record #2 and "books", however this should not work because record #2 is deleted. So when your book method calls the find method with "2" as the parameter, it should throw a RecordNotFound exception because the record no longer exists, it has been deleted. And in the assignment case, it is still in the file, just has the delete flag set.
Hope that helps.
Mark
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Mark Spritzler:
I think the idea that record number is the actual number in order in the file, and a primary key, there is always this confusion. a Primary key can also be a "unique" key, like you have pointed out. So the DuplicateKeyException in the add method is very logical. If you pass a record that has the same name and location that already exists in the database, then you should not add it, it should throw the exception. Just like a unique constraint in Oracle or SQL Server would throw an error.

Thats my take on it. Thats how its coded now I dont really like the read method using the order in which they come as a key as it forces the assumption that this order is sacred. However the project is about assumptions so there we go
Originally posted by Mark Spritzler:

Now the find method could throw a RecordNotFound error in the case of a record number that has been deleted. So client A searches and find 3 records, record #1, 2, 3. Client B deletes record #2, then client A selects record #2 and "books", however this should not work because record #2 is deleted. So when your book method calls the find method with "2" as the parameter, it should throw a RecordNotFound exception because the record no longer exists, it has been deleted. And in the assignment case, it is still in the file, just has the delete flag set.
Hope that helps.
Mark

I vehemently disagree on this one though. I understand RecordNotFoundException on the read() method. But the find() method returns an array of recNo. It expects nothing. It demands no specific record. It is totally passive in its demands. You can return 1000 rows or you can return null and both returns are valid. So it doesnt matter how many records are deleted, as the find method ignores them. And if thread 2 deletes record 2 whilst thread 1 returns an array 1,2,3 there is no problem whatsoever UNTIL thread 1 calls read(2). RecordNotFoundException works for read(), not for find().
The only use for it in my solution is to nest an IOException in the event of some connection failure to the file. This is an appalling use of exceptions.
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
{I had comments written here, but they vanished: in short: if you
decide not to throw record not found exception from find(),
best not to return a null array, but an empty one (which is
a more standard way to go)}.
{I had comments here, but they vanished}

In short, IOExceptions can't have a "cause".
Nevertheless, you can, if you desired to, and the only reason
would be to get this information to the client side (assuming,
perhaps, that asking people to look through logs might be
overly time consuming), use software to place the exceptions
into a string-type array, then re-throw thus:
throw new SomeOtherException(array-of-stack-trace-as-string.toString());
For into on how to capture the stack trace info, see
Java Sun documentation API for Exception and its
super-classes.
Thanks,
Javini Javono
[ January 24, 2004: Message edited by: Javini Javono ]
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Can you create a zero element array? Id never even thought to try new int[0]
You can go years programming a language and still find freaky stuff you had never thought of in the simplest things.
[ January 24, 2004: Message edited by: morgan bath ]
 
Javini Javono
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Both ways work:
int[]myInt1 = new int[0];
int[]myInt2 = new int[] {};
Thanks,
Javini Javono
 
Morgan Bath
Ranch Hand
Posts: 196
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The bizarre thing is, im doing that in my code already, I initialise arrays with a variable (that is often zero) all the time, but ive never actually written new int[0] and so Id never really conciously thought about zero element arrays before.
Its quite scary actually the number of things you assume in your code without actually knowing 100% of the actual realities. Im a little wiser tonight
Actually stuff like this happens a lot for me. It took the programmer exam before I found out all the different ways the appearance of default constructors and super() can screw you up
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic