• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Rob Spoor
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Henry Wong
  • Liutauras Vilda
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Tim Holloway
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
Bartenders:
  • Al Hobbs
  • Mikalai Zaikin
  • Piet Souris

Single Data Interface Justification

 
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone,
I'm trying to justify the use of a single data interface in my design document. In my view the DataAccess interface provides the client access to the database (API), whilst hiding the actual implementation i.e local or remote from the client. If this is true, then client must therefore catch both DatabaseExceptions and RemoteExceptions.
The implication of this is that the DataAccessLocal implementation must delcare that it throws RemoteException as it extends remote, whilst never actually throwing the exception. I would argue that if a client only required local mode that it could us the Data class.
Any comments?
Thanks
Jason.
 
ranger
Posts: 17346
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

If this is true, then client must therefore catch both DatabaseExceptions and RemoteExceptions.


Actual in my DataAccessFacade, which the client uses. I catch the DatabaseException, then I also catch Exception, in the catch of the Exception, I create a new DatabaseException, put a nice message in it and then throw the DatabaseException. This way the client only has to catch the DatabaseException.

Also why not just have your DataAccess interface throw Exception? It is generic and allows you to throw the more appropriate exceptions in the implementation class.
Mark
 
Jason Moors
Ranch Hand
Posts: 188
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Mark,
I'm in two minds about the interface throwing Exception, whilst it provides flexibility for future implementations to throw exceptions derived from Exception, it means that the client class must catch Exception. This in my experience is a bad thing as you may catch exceptions which should propagated higher up the application.
Thanks for you're input
Jason.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The implication of this is that the DataAccessLocal implementation must delcare that it throws RemoteException as it extends remote, whilst never actually throwing the exception.
Not true. The implementation class need not declare any exceptions. But any remote interface it implements will need to declare throws RemoteException for all methods, and the rmic-generated stub class will have methods that really can throw those exceptions. But

Here Data implements two interfaces, identical to each other except that one is remote and the other isn't. You can use Data locally and refer to it using the DB interface, or you can use it in network mode and refer to it with the RemoteDB interface.
The main problem I see with this is that it may not have sufficient separation between the networked code from the non-networked code, as required in the instructions. When in local mode we're still instantiating a class that extends UnicastRemoteObject, even though it never gets used as a remote object. So that's a bit weird, but I think it may be acceptable. Personally I'd rather have separate classes to handle the network connection, but this is an option at least.
 
This tiny ad is guaranteed to be gluten free.
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic