Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: RemoteException for RMI

 
Nicholas Cheung
Ranch Hand
Posts: 4982
  • Mark post as helpful
  • send pies
  • 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.
 
Ulrich Heeger
Ranch Hand
Posts: 266
  • Mark post as helpful
  • send pies
  • 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
  • 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?
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • 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
  • 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
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • 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...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic