• 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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

NX: RemoteException for RMI

 
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The information sheet defines the following function for me:

Thus, I implemented this function in the Data.java.
And I have defined an interface Services.java, which defines the read() function (called by the client GUI).
It works well for local connection.
But when I try to implement the RMI model, the complier complaints that, my RemoteServices.java interface (which implements Services.java), do NOT throw RemoteException.
Thus, what should I do?
Should I simply add the RemoteException to the Services.java interface, or I should have 2 interfaces, one is called for local (Services.java), the other is called for remote (RemoteServices.java NOT implements Services.java) to handle this case?
Thanks.
 
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Nocholas,
I had a similar problem. Look at this thread, perhaps you can get some help there.
Greetings
Ulrich
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That is to say, I have 2 interfaces, one is Services, and the other is RemoteServices.
Both can be constructed from the Adapter (my adapter is ServicesImpl).
If a local connection is made, I got the instance with Services.
If a remote connection is made, I got the instance with RemoteServices.
And in addition, the only different % the 2 interfaces is that, methods in RemoteServices throws RemoteException, while Services do not?
But then, seems we exactly duplicate the 2 classes, but just for different exception thrown?
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
But then, seems we exactly duplicate the 2 classes, but just for different exception thrown?
Yep. It's annoying, but it's a fairly standard solution for this problem. In Max's book he gets around this by defining the original interface methods to all throw IOException. RemoteException is a subclass of this. So there's no need for a second interface, which is nice. But we don't have that luxury if the interface was defined for us, with no IOException. If you use RMI, and are given an interface that doesn't allow RemoteExceptions, I think you have to define a second interface; I haven't seen any alternate solutions to this.
 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I get what you mean, but what if:

And no matter local or remote, I use the same interface?
I guess this is not so good, but I wanna know the reason why we should avoid such declaration?
Thanks a lot.
 
Jim Yingst
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Oh, I see - your Services interface is not the one Sun defined for you, right? All right, you can define this how you want then. One possible problem with this definition though is the requirement

Keep in mind that networking must be entirely bypassed in the non-networked mode.


Now this isn't an exact requirement, but to my mind I'd prefer that my non-networked code avoid any mention of networking-related classes at all. Using an API that mentions "throws RemoteException" forces the client to catch RemoteException, which means the client has to know at least a tiny bit about RMI. And what if you want to change your networking to use sockets later? I'd prefer to insulate all other classes from any knowledge of whether networking is involved, or whether it uses sockets or RMI.
Now you could use Max's solution and declare throws IOException rather than throws RemoteException. That's a bit more palatable to me. Would make more sense if other IOexceptions were propagated this way, but Sun's interface makes this difficult. But that's another discussion...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic