I am wondering if it is more appropriate for lock method to throw DatabaseException (just like all other public methods except constructor, in Data class wrap IOException into DatabaseException) instead of throwing IOException ? The supplied documentation says that it throws IOException if the record position parameter is invalid. To keep the code more consistent, I feel, lock too should throw DatabaseException, that way it is easy to always catch DatabaseException on the client side. Any thoughts ??
One thing (out of a few) to consider: are the exceptions functionally necessary? I consider the lock() method functionally essential because without knowing whether it succeded or not you cannot determine whether you can continue with your operation. And this is requirent-driven. So exception throwing is necessary. For the unlock() it's a bit more complex. I take a 'best effort' approach. Once, you have locked and executed you operation you want unlock the record, however it's not vital for your client to know if unlock() has succeded to continue with its other business. My unlock() does it's best to unlock a record, if it fails it may or my not throw a (Remote)Exception but the ClientData object handles it and never bubbles it up to the business component. [This message has been edited by Gennady Shapiro (edited November 15, 2001).] [This message has been edited by Gennady Shapiro (edited November 15, 2001).]
posted 18 years ago
thanks for your response. but my question was not whether lock should throw exception at all, but whether it should throw DatabaseException rather than IOException just like all other public methods wrap IOException into DatabaseException. thanks
posted 18 years ago
ok.sorry for misunderstanding. hers my thinking. I have a Connection interface that is implemented by FileConnection and RMIConnection. RMIConnection requires throwing of RemoteException, now since RemoteException is subclass of IOException all my Connection objects throw IOExceptions to the client. so heres the exception flow: Data->(DatabaseException,IOException) -> Connection (IOException, RemoteException) -> ClientData (ConnectionException) -> Client the important thing is that the Client receives only Connection exceptions. The reason is the Client deals with an abstract connection and doesnt know what it represents (could be a file, a relational db, a guy sending emails to fulfill your requests, doent matter). hope this helps.
My design is thusfar quite different from the one Gennady has laid out, but I do see where he's coming from. The original question, "should Data.lock() throw IOException?" remains a question for me though... IOException seems to be better suited to notifications about more basic errors. The lock() functionality is something specific to the database, not the network. Does anyone have thoughts on changing the exception on lock() to DatabaseException? I'm not planning on implementing any lock/unlock functionality in Data -- the plan is to pass these calls along to a LockManager. e