On Sun, 28 Oct 2001 20:39, Paul Hammant wrote:
> Peter,
>
> >>>Even if we were to create
> >>>Avalon Method Invocation we would still need a AMIException for the same
> >>>use anyways,
> >>
> >>Yes but extend RuntimeException not Exception. GLUE does this and it is
> >>seamless.
> >
> >I like the fact that Remote is not a runtime exception. It forces the
> >developer to write code that behaves nicely in a distributed environment.
> > You should be catching this down low and dealing with them gracefully
> > IMHO ;)
>
> It forces the developer to catch RemoteException at each invocation of a
> remote method. What to do with it?
I usually do something like
Client.remoteException( "Description of what I was doing",
myRemoteException );
> I catch a lot of coders declaring
> it in throws to decrease the amount of code they have to write, suddenly
> you find throws RemoteException proliferating around a system. What to
> do with it?
Bad programmers will write bad code regardless of what you do.
> Try again? Hmm, Typically people have new exceptions like
> "QuoteServiceFailedException" and wrap the remote in that before
> throwing it.
Wrapping exceptions before propogating them up is a standard practice. I do
it all through my code and avalons code ;)
For instance something I was debugging the other day had exceptions nested
like
ActionException -> PersistenceException -> SQLException
> I've had nothing but misery since 98 with RemoteException.
> It's a major pain in the ass that, strictly speaking, you can't even
> test. No I really do prefer handling wobbly connections at a single
> handler level in an API.
See above for an example of that. However choice - especially when it is more
than a simple client-server setup is important.
> >They fixed this in EJBs because now EJBs no longer have to implement the
> >remote interface - yaya!!!!! I have thought about doing a
> > proxy/wrapper/stub compiler that just exported local version and was
> > automagically generated. In a perfect world the setup per class would be
> > something like
> >
> >interface Foo
> >{
> > void doStuff();
> >}
> >class FooImpl implements Foo {}
> >
> >interface RemoteFoo extends Foo
> >{
> > void doStuff() throws RemoteException;
> >}
> >class RemoteFooStub extends RemoteObject implements RemoteFoo { ]
> >
> >The first two would be human created while the second two would be
> > computer generated.
>
> I Just don't like it Peter.
I know ;)
> Now RMI should continue to be used for client to server comms (JAMES and
> FTPServer use it for admin), but I really donlt think we need it for the
> inter-sar communication. Sun, sooner or later, are going to come along
> with a fresh replacement RMI. They are not adverse to such efforts
> (look at nio package in JDK1.4). That replacement is going to be a lot
> easier to use because it will be seamless. The RMI registry needs an
> overhaul too.
RMI registry is only a toy API that grew as is some of the infrastructure.
However what I am talking about is the model. Whether it actually uses any of
the RMI code or rewrites it all (ie RMI/IIOP, RMI/JAXM, RMI/JRMP in EJB
servers, etc). I still think that being forced to deal with errors where they
are likely to occur is a good thing.
I guess we will have to agree to disagree ;)
--
Cheers,
Pete
When a stupid man is doing something he's ashamed of, he always
declares that it is his duty.
George Bernard Shaw
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
