Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
JavaRanch.com/granny.jsp
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird  1.1.1 Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "URLyBird  1.1.1" Watch "URLyBird  1.1.1" New topic
Author

URLyBird 1.1.1

Eva Van Shtock
Greenhorn

Joined: Jun 02, 2006
Posts: 28
Hello,

I just started doing this assignment and I was wondering if someone can help me.

In the DB interface:

public int create(String[] data) throws DuplicateKeyException;


The database, as defined by Sun, does not have Primary key. Furthermore, no combination of the fields can be used as a primary key.
It is perfectly legal, as I can see, to have two rooms with same field values.

Now, for this create method implementation, what should I do. I can perfectly ignore this DuplicateKeyException. Is it wise?
Can I throw it in the case of IOException? I think I should since I cannot define new Exceptions.


What you all think?


Please help.

Eva
B Chen
Ranch Hand

Joined: Dec 27, 2005
Posts: 89
Your create() method don't need to throw DuplicateKeyException if the implementation doesn't have a need to do so. You can even leave the throws specification out.
Using DuplicateKeyException for any other reason (to handle IO exceptions) would not be a good idea.


SCJD<br />SCJP 1.4
Eva Van Shtock
Greenhorn

Joined: Jun 02, 2006
Posts: 28
Chen,

That would be a good advice. Howver, what can you return to the user?
The interface method is given as:

// Creates a new record in the database (possibly reusing a
// deleted entry). Inserts the given data, and returns the record
// number of the new record.
public int create (String[] data) throws DuplicateKeyException;


As I said before, nothing in the database (single or combined) can be used as a primary key.
What should I return to the user? If I return -1, it is still an integer and he will use it as record number!

I see no other choice but to use the DuplicateKeyException as an indication for failure.

I'm open for any suggestions.

Eva
B Chen
Ranch Hand

Joined: Dec 27, 2005
Posts: 89
The primary key can be anything that uniquely identifies a record. It does not have to be in the data itself. So what do you think can serve as the primary key in this application?
Eva Van Shtock
Greenhorn

Joined: Jun 02, 2006
Posts: 28
Chen.
I can use anything for the primary key. I could easily use sequence number.
The question is how can duplicate key error occur? The client give me a record to add and you never get duplicate record! As I said before, there can be identical rooms in the DB and it is OK.

So, is it a design decision to use this exception for DB access error etc.?

Regards
Eva
B Chen
Ranch Hand

Joined: Dec 27, 2005
Posts: 89
Yes, it would be a design decision. But most developers would agree it is a bad design decision. There are better ways to handle access errors.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11484
    
  94

Hi Eva,
The question is how can duplicate key error occur? The client give me a record to add and you never get duplicate record! As I said before, there can be identical rooms in the DB and it is OK.
Sun have stated in the past that some parts of the assignment deliberately emulate users who are asking for things that contra-indicate either other parts of the assignment or even just what we would expect. In real life, we would be expected to go back to the customer and talk through the problems with them. Sun want to see that as developers we can spot the issues, think of solutions, and then describe the solution we decided to go with in our design decisions document.

So, yes, it is possible that you could have two identical rooms, which makes the DuplicateRecordException redundant.
So, is it a design decision to use this exception for DB access error etc.?
As B Chen says, this is a design decision, but it might not be the best design decision.

Think about it from the perspective of a junior programmer who has just joined the company and has to work with your Data class. They start looking at the create() method, and notice that it can throw a DuplicateRecordException. Why would they expect that to mean anything other than the fact that there is a duplicate record? Telling them that a DuplicateRecordException might be thrown if there is a duplicate record, or if there was a permissions problem, or if there was an IO problem, or if there was a .... is just going to confuse them.

Wouldnt it be better if the Create method threw DuplicateRecordException and DBAccessError? (Hint, take a look at what java.lang.RuntimeException can offer you.

Regards, Andrew


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
Also consider that while the supplied record format does not contain a unique key (and thus will never have a duplicate key) the DB format is a generic one that can be applied to other record definitions that DO have a key.

That's one reason why I created my entire database structure as a generic system, with subclasses where needed for the specific implementation required for the assignment.
That way if a table were to be added only 3 classes would have to be created on the serverside to support it (a class for the file operations, one for the metadata, and a class to serve it over RMI).
I'm still somewhat uncertain about it though, I feel it can be made more generic still at the cost of slightly higher complexity and am not sure whether to do so or not.


42
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: URLyBird 1.1.1