This is referred to validation on the data access level: update and create. What should I do with a null string for a field? (surely it is best to be filtered at client and business logic, but sun's testing can directly call on this level.)
For example: I think of options for create (this is not required in client and thus in business logic): 1. disallow null field -- exception 2. replace \0 padding with spaces 3. simply don't verify.
The option 3 is error prone, since if the last field for create is null, it will result in an incomplete data format.
Andy, checking for a null values depends on the business logic of specific method. Sometimes it is acceptable and sometimes it is not. For example: a primary key field in a record cannot be null, and an optional field might be ok to be null. If you don't allow null values in your methods, you must throw a checked exception and mention that in the method documentation. You can use IllegalArgumentException or NullPointerException. Personally, when I validate passing parameters, I use IllegalArgumnetException.
SCJD 1.4<br />SCJP 1.4<br />-----------------------------------<br />"With regard to excellence, it is not enough to know, but we must try to have and use it.<br />" Aristotle
Joined: May 26, 2004
Thanks, Hanna. You made some good points. But even the definition of primary key in this assignment is vague. But the illegal arg ex is a way to handle it.