On your way in you may have missed that we have a JavaRanch Naming Policy for displayed (screen) names. Your displayed name must consist of a first name (or an initial), a space, and a family name (in that order) and not be obviously fictitious. Since yours "Tim A...", does not conform with it, please take a moment to change it, which you can do right here.
Posters with nonconforming displayed names will be locked out of JavaRanch after a few posts using those names.
Originally posted by Tim A...: How do you handle IOExcetion's in the Data class ? MI got serveral solutions but I don't know which I should take...
1. Do nothing --> just printing stackttrace ( surly horrible ) 2. throw RemoteExcetion 3. Throw a DatabaseException ( checked or unchecked ? )
I think solution 3 is the best one, but I don't want to change the given interface. Therefore I would use an unchecked Exception.
Does someone has a better solution ?
Do your Data methods throw RemoteExceptions?, because this is also a checked exceptions that need to be specified in the method declaration. Your two main options are either wrap the exception in one of the checked exceptions such as RecordNotFoundException or define your own runtime exception and wrap the IOException in that. Both would be considered bad programming practice so pick whichever you think is the lesser of two evils.
Originally I was wrapping IOExceptions in the checked exceptions but I changed to unchecked exceptions later as I felt that it was better to keep the meaning of RecordNotFoundException to solely mean that a record does not exist. Also I think that an IOException should be a rare enough occurance to make throwing a runtime exception acceptable.
My networked database access uses a decorator around my Data class which wraps its operations and throws RemoteException. The network proxy in turn is set to throw IOExceptions so it's independent of the type of networking used (RemoteException inherits from IOException).
The Data class itself wraps what IOExceptions it gets in unchecked DatabaseExceptions which percolate up through the Remote and its proxy.