Client/server RMI app using Command pattern: return values and exceptions

Question

I'm developing a client/server java app via RMI. Actually I'm using the cajo framework overtop RMI (any cajo devs/users here?). Anyways, there is a lot of functionality the server needs to expose, all of which is split and encapsulated in manager-type classes that the server has access to. I get the feeling though that bad things will happen to me in my sleep if I just expose instances of the managers, and I really don't like the idea of writing 24682763845 methods that the server needs to individually expose, so instead I'm using the Command pattern (writing 24682763845 individual MyCommand classes is only slightly better). I haven't used the command pattern since school, so maybe I'm missing something, but I'm finding it to be messy. Here's the setup: I've got a public abstract Command which holds information about which user is attempting to execute the command, and when, and lots of public MyCommands extending Command, each with a mandatory execute() method which does the actual dirty work of talking to the model-functionality managers. The server has a command invoker executeCommand(Command cmd) which checks the authenticity of the user prior to executing the command.
What I'm interested in is return values and exceptions. I'm not sure if these things really fit in with a true command pattern in general, but it sure would be nice to have return values and exceptions, even if only for the sake of error detection.
First, return values. I'd like each Command to return a result, even if it's just boolean true if nothing went wrong, so in my Command class I have a private Object result with a protected setter, public getter. The idea is, in the execute() method, after doing what needs to be done, setResult(someResult) is called. The invoker on the server, after running acommand.execute() eventually returns acommand.getResult(), which of course is casted by the client into whatever it should be. I don't see a way to do this using generics though, because I don't see a way to have the invoker's return value as anything other than Object. Suggestions? All this means is, if the client were sending a GetUserCommand cmd I'd have to cast like User user = (User)server.executeCommand(cmd), or sending an AssignWidgetToGroup cmd I'd have to cast like Boolean result = (Boolean)server.executeCommand(cmd). I guess that's not too bad, but can this be done better?
Second, exceptions. I can have the Command's execute() method throw Exception, and the server's invoker method can in turn throw that Exception. Problem is, with a try/catch on the client side, using RMI (or is this just a product of cajo?) ensures that any exception thrown by a remote method will come back as a java.lang.reflect.InvocationTargetException. So for example, if in MyCommand.execute() I throw new MySpecialException, the server's command invoker method will in turn throw the same exception, however the try/catch on the client side will catch InvocationTargetException e. If I do e.getCause().printStackTrace(), THERE be my precious MySpecialException. But how do I catch it? Can it be caught? Nested try/catch won't work, because I can't re-throw the cause of the original exception. For now, instead of throwing exceptions the server is simply returning null if things don't go as planned, meaning on the client side I would do something like if ((result = server.executeCommand(cmd)) == null) { /* deal with it */ } else { /* process result, continue normally */ }.
So using the command pattern, although doing neat things for me like centralizing access to the server via one command-invoking method which avoids exposing a billion others, and making it easy to log who's running what and when, causes me null-checks, casting, and no obvious way of error-catching. I'd be grateful if anyone can share their thoughts/experiences on what I'm trying to do. I'll post some of my code tomorrow to give things more tangible perspective.

Answer 1

First of all, thanks for taking the time to read, I know it's long.
Secondly, pardon me, but I don't see how you've understood that I wasn't going to or didn't want to use exceptions, considering half my post is regarding how I can use exceptions in my situation. My love for exception handling transcends time and space, I assure you, that's why I made this thread.
Also, you've essentially told me "use exceptions", "use exceptions", and "you can't really use exceptions". Having a nested try/catch anytime I want to catch the real exception does indeed sound terribly weak. Just so I'm on the same page though, how can I catch an exception, and throw the cause?
try {
catch (Exception e) {
     Throwable t = e.getCause();
     // now what?
}Actually, nested try/catches everywhere is not happening, which means I'm probably going to ditch cajo unless there's some way to really throw the proper exception. I must say however that cajo has done everything I've needed up until now.
Anyways, what I'd like to know is...what's really The Right Way (tm) of putting together this kind of client/server app? I've been thinking that perhaps RMI is not the way to go, and I'm wondering if I should be looking into more of a cross-language RPC solution. I definitely do want to neatly decouple the client from server, and the command pattern did seem to do that, but maybe it's not the best solution.
Thanks again for your response, ejp, and as always any comments and/or suggestions would be greatly appreciated.