• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

URLyBird: Data Validation in database code

 
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.

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

POSSIBILITIES???
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.

MY SOLUTION:
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?

Doug
[ February 10, 2005: Message edited by: Doug Newcomb ]
 
Doug Newcomb
Greenhorn
Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 {
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic