File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes URLyBird:  Data Validation in database code 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:  Data Validation in database code" Watch "URLyBird:  Data Validation in database code" New topic

URLyBird: Data Validation in database code

Doug Newcomb

Joined: Jun 16, 2003
Posts: 6
Hello All,

I have completed my database code, and it works great... even the locking (I plan to break the 44/80-points barrier on locking). I recently realized that I've implemented the database code to allow:

- More options than just the 'N' and 'Y' options for the smoking field.
- More options than numeric digits for the occupancy, and owner fields.
- More options than a currency symbol, digits and a decimal for the price field.

In my mind this is a bit of a data validation hole... and a bit of a puzzle as well.

If we have been given an interface that does not allow a db implementation to throw an application exception that can cover data validation exceptions, what should we do?

Should we...
- A: throw a RuntimeException? (I don't think this is wise)
- B: Ignore data validation? (I like this better, but still lame)
- C: Overload an existing exception like RecordNotFoundException, or DuplicateKeyException (this would handle the problem, but is overly confusing for an implementor... another lame answer).

THE PUZZLE: (as I see it)
In a perfect world, if a user of the dbAccess interface wanted to update a record (using the update method) with an 'A' in the smoking field instead of an 'N' or 'Y', the db code would catch this fault, and explicitly throw an application exception letting the caller know that there were problems with the update. This really should be done since the insertion of improper data could be looked at as corruption of the database. BUT... we can't throw an application exception because our interface is already explicitly defined for us. Also, it would be important NOT to throw a RuntimeException because we wouldn't want the application to ever die just because the DBAccess user wasn't smart enough to submit proper data.

So far, I'm opting for option "B", I plan to provide copious comments (warnings) in code and the choices.txt document describing this decision, and I plan to perform my data validation within my business logic layer (not in the database code at all).

Does anyone else have a solution to this problem?

[ February 10, 2005: Message edited by: Doug Newcomb ]

- "Wise men talk when they have something to say..." (I think I should shut up now).
Doug Newcomb

Joined: Jun 16, 2003
Posts: 6
Looking back through the JavaRanch archives I've found that this is no new puzzle.

It looks like the most accepted answer is close to option C: above.

Looks like people are "chaining" exceptions within the RecordNotFoundException.

Links to previous discussion on this:
here is a debate on Jared Chapman's approach to this problem.
here is an excellent discussion of exception handling from the DbAccess interface.
dennis du
Ranch Hand

Joined: Dec 31, 2004
Posts: 59
For me,I used the negtive return value to show error.
So I did not need to use the RecordnotFoundException.
For it is urgly.

* @return 0=success -1=Owned by others -2=Time is
* expired -3=Time not reached(in 48 Hours rule).
public int bookRecord(int recNo, String[] data) throws
RecordNotFoundException {

-------------------------------<br />OCP 9i <br />SCJP/SCJD/SCWCD(92%)/SCDJWS<br />XML(IBM Test 141)<br />Who is the next?SCBCD<br />SCBCD/CCNA/CCNP/PMP<br />not sure
jQuery in Action, 3rd edition
subject: URLyBird: Data Validation in database code
jQuery in Action, 3rd edition