Win a copy of Five Lines of Code this week in the OO, Patterns, UML and Refactoring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

URLyBird: Data Validation in database code

Posts: 6
  • Mark post as helpful
  • send pies
  • 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.

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 ]
Doug Newcomb
Posts: 6
  • Mark post as helpful
  • send pies
  • 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
  • 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 {
I'm not dead! I feel happy! I'd like to go for a walk! I'll even read a tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic