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).