[B&S] Construction of a data row Object

[Russell Wurth]

Hi all, first post, great forum. Max, excellent book, good examples and a perfect way of presenting Java without giving away a solution to the SCJD!!

I have a class called DBRecord to represent a row in the database, taking a String[] as a constructor parameter. This is due to the requirements of implementing an interface that returns String[] from a read() and passing String[] for create() and update().

DBRecord has variables for the field values, 3 of which are numbers that I am storing as a short (for size and owner) and float (for rate).

I would like to know how I should handle NumberFormatExceptions. My design calls for throwing InvalidDBRecordException if there is a problem creating the DBRecord object. This exception could (but probably not for SCJD) be thrown for values out of range, invalid format, exceeding size, etc.

So when I construct my object in this way:

DBRecord(String[] fieldData) {
   this.name = fieldData[0];  // String variable
   this.size = Short.parseShort(fieldData[3]);  //line of code in question
}

Which solution is the best practice/design:
1. put a try/catch(NumFormatEx) in my DBRecord constructor for the group of numeric fields that I am parsing from a String and catch it, throwing a new InvalidDBRecordException which I declare in my constructor (throwing the new Exception may be too much)

2. call a setField() method within the constructor for each String array element that I need to parse to a number, each one containing try/catch and being able to throw a more detailed InvalidDBRecordException stating what field had a problem parsing to a number.

3. Assume that the String[] will be properly formated and perform no checks
4. Keep all my data types as Strings (seems like bad practice)

I realize that performance suffers from having excessive try/catch blocks, I'm more curious about overall design and any real-world experience that anyone has to share.

Thank you

Russell

[Andrew Monkhouse]

Hi Russell,

Welcome to JavaRanch and this forum.

1. put a try/catch(NumFormatEx) in my DBRecord constructor for the group of numeric fields that I am parsing from a String and catch it, throwing a new InvalidDBRecordException which I declare in my constructor (throwing the new Exception may be too much)

Do you also intend to have getters and setters for each of these fields? In which case, are you going to have duplicated try/catch blocks?

I agree with the concept of creating your own exception.

Regarding your comment that throwing the exception may be too much - if you don't throw it, how will the creator of this object know that it does not have a valid object?

2. call a setField() method within the constructor for each String array element that I need to parse to a number, each one containing try/catch and being able to throw a more detailed InvalidDBRecordException stating what field had a problem parsing to a number.

This answers the first issue I had - having a setField() method then ensures that your tests are all in one common place. If the business rules change, then you only have to fix one section of code.

3. Assume that the String[] will be properly formated and perform no checks

Dangerous - your instructions (probably) state that the whole project is going to be rewritten in the near future, but that you should write for future enhancements. In which case, if they throw away the code which uses this Value Object, but still keep the Value Object, then you could end up with your code appearing to be buggy.

4. Keep all my data types as Strings (seems like bad practice)

But it is the simplest solution for the assignment . You probably have a statement in your instructions telling you that you will not get extra marks for going beyond the requirements of the instructions.

In real life I tend to use option 2.

For this assignment I personally stuck with option 4.

Whichever you choose is unlikely to lower your eventual mark. As this is a design decision, you should document the final choice (which gives you the chance to show the examiner that you do think about these issues).

Regards, Andrew

[Robert Konigsberg]

I also stuck with #4. You're right to think about this problem. I suspect everyone who handles this assignment has the same problem. What you've highlighted is that it's a design choice that you might want to consider. In other words, in my document I should have made clear that the interface does not imply that the numbers would be valid values.

One thing: to make things easier, the internal representation of the object is still String[]. My getters and setters still just operate upon the array elements. Additionally I have two constructors: cons() and cons(String[]) and a String[] toArray() method. That way I can use the String[] within my JTable TableModel. That's something for you to chew on.

RK

[Russell Wurth]

Robert and Andrew,

Thank you for the reply.

I concur, it's probably overkill to have the specific numeric data types as int/float for the scope of this project.

Along the same lines, did you validate the booking Customer ID, which is supposed to be numeric, on the client, or within the server or data object?

I'm thinking data object, then the GUI/client has to catch any exception thrown for invalid ID.


Russell

[Robert Konigsberg]

I don't recall anything documenting a valid customer ID. The only thing I did was ensure that the field's length was no greater than the customer id size as stored in the database.

RK

[Andrew Monkhouse]

Hi Russell,

It is generally a good idea to open new questions in new topics. That way readers who might skip the original topic title may read the new one. And people doing searches in this forum can see from the topic line what is likely to be discussed.

Along the same lines, did you validate the booking Customer ID, which is supposed to be numeric, on the client, or within the server or data object?

I had a different requirement, which had a variable length numeric to be validated. I set up my GUI such that only numeric values could be entered, and those values had to be within the correct sizes. I then did further validation once the user hit the "book" button, and on the server side.

Regards, Andrew