Why did I rabbit on about the Liskov Substitution Principle anyway? Because the infamous RemoteException is an example of the issue.
In a “location transparent” mode of working, you don’t know if the object you are talking to is collocated in the same JVM, or halfway around the world. You can literally substitue the remote object for the local one; the LSP at work.
However, when you’re talking to a remote object, you need to deal with the problem that distributed applications aren’t very reliable. Thus, the java.rmi.RemoteException
was born.
But a RemoteException can’t be a runtime exception; otherwise when you drop the remote object in, you’d risk breaking the client code (which isn’t expecting runtime exceptions to propogate out). Thus, it has to be checked.
If it’s checked, however, the client code must always deal with RemoteExceptions. Only if the client says “Okay, I’ll just use a local version” can you ignore them.
This is a good example of the LSP at work; if you want the ability to substitue a remote object for a local one, you need to have an interface contract which permits the substitution. If you don’t, then you out of luck.
(Location transparency is an odd concept, BTW; many people interpret it to mean that remote objects are treated the same as local, which is why they complain about the RemoteExceptions. The correct intepretation should be that local objects get treated as remote)