Logging an exception is of course better than just swallowing (ignoring) it and doing nothing at all. But I think just logging them is just not enough. If you can't handle them appropriately in the Data class you should propagate them to the next layer. You suggest using a simple RuntimeException, but it might be better to use a specific (custom created) DBException (which is a runtime exception). So you can catch it in the next layer and handle appropriately.
One more thing... I quite dislike checked exceptions and more fond of sub-classing RuntimeException (read here summary). How Oracle/Sun looks at the use of RuntimeException sub-classes instead of checked exceptions? Won't it be considered "bad practice" (still I would add @throws in javadoc...) or should I explain in choises.txt why I chose subclassing RuntimeExceptions and all will be ok? Also there is this paper which in summary says that I should not use unchecked exception in my code (but in this specific case, that I mentioned in first post, it seems to be ok to propagate RuntimeException) . I am confused :/
Tadas Subonis wrote:or should I explain in choises.txt why I chose subclassing RuntimeExceptions and all will be ok?
I think the explanation writes itself (and is completely useless). If you throw a checked exception (like IOException) from e.g. the read-method, your code would not compile, because this exception is not declared in the given interface. So you can only use runtime exceptions in the Data class to throw (besides RecordNotFoundException).
I think you should carefully choose if you opt for a checked exception or a runtime one. If you do it carefully, exception handling will be a very powerful (and useful) asset. But if you do it wrong, it will result in a code mishmash (hard to maintain, extend,...)
Roel, if you have DBException or, for example, InvalidDBException as unchecked (Runtime) exceptions how do you inform the user that problems reading file occur (in my case InvalidDBException throw if database file does't exist or magic cookie value is wrong and these situations hit to recoverable conditions (therefore checked exceptions)) ?
By catching and handling the InvalidDBException appropriately.
For example when user enters/selects the database location (to start the standalone client), I try to load the records into my cache. If that's not working because magic cookie is wrong, the user gets an information dialog and then application exits.
Certainly not! You maybe could lose some points, because not using it consistently throughout your application or you used an unchecked exception while the situation required a checked one. But that's just a wild guess, because I'm not an accessor.