You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Paul Hammant <pa...@yahoo.com> on 2001/10/28 13:38:07 UTC
RemoteException (was Minutes from AvalonCon #1 )
Peter,
>>>>I guess we will have to agree to disagree [;)]
>>>>
>>
>>
>>Another way of looking at it is - do you think that it is good or bad that
>>most database classes declare they throw SQLExceptions? I see it as good - u ?
>>
>
Slightly different. Bad if I had to choose. Bad perhaps mostly cos
there is no hierarchy. e.g. BadInsertException,
MalformedSQLstatementException, ManadatoryRecordNotFoundException.
IOException bad for java.io methods too, though it does have a hierarchy.
RemoteException is different because it is etherial and can't be tested
by mortals. It it did extend RuntimeException your could /choose/ one
of a couple of strategys for handling ( where it happens, or in central
handler code).
Another example is the curious Interger method :
public static int parseInt(String s) throws NumberFormatException
It's exception is a RuntimeException derivative. i.e. you don't have to
handle it inline if you don't want to.
I'll refer you again to Glue. It's simple. It has negligible overhead
in terms of coding effort but does allow the exceptional communication
of failing net availability.
>From Other Email
================
>> Client.remoteException...
Yes I do that too (have to)
> [ wrapping of Exception rife in Avalon and other projects ]
Yes, that's fine it works well. When one is coding for Avalon one is aware of Avalons rules.
My point is that if there is a jar available out there that does say crypto ( String
encrypt(String msg, int key) ) and one wanted to remote publish it's service, with RMI the effort
is hude and usage cumbersome. With Glue it is easy to do and simple to use.
I.e. My simple assertion is that an API should seemingly be as easy to use remotely as locally.
Glue is, RMI not.
> I still think that being forced to deal with errors where they are
> likely to occur is a good thing.
I think the choice as to where to handle failing net services is a good
thing. I'm not proposing you don't handle exceptions in line (you can
catch a RemoteException derivative anywhere you like). My proposition
for a different RMI is about choice, not forced behaviour/coding.
> Agree to differ
I guess so - my MEMEs are not infectious [:-(]
Regards,
- Paul H
____________________________________________________________
Nokia Game is on again.
Go to http://uk.yahoo.com/nokiagame/ and join the new
all media adventure before November 3rd.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RemoteException (was Minutes from AvalonCon #1 )
Posted by Peter Donald <do...@apache.org>.
On Mon, 29 Oct 2001 07:50, Paul Hammant wrote:
> Peter,
>
> >>I.e. My simple assertion is that an API should seemingly be as easy to
> >> use remotely as locally. Glue is, RMI not.
> >
> >keyword in that sentence - "seemingly" ;)
> >
> >If it seems as easy to use locally as it is remotely then you will have
> >people treat it like a local object. This is *extremely* bad if you are
> >trying to build a fault tolerant infrastrcutre. The more strongly typed
> > and more easily that tools (ie compilers and whatnot) can tell me I am
> > doing stupid things (like treating remote objects as locals) the better
> > IMHO. With RMI as it is now you have to make a choice to program poorly.
> > With the GLUE model you have to make a choice to program properly. Hence
> > why I like RMIs model ;)
>
> Could you at least agree with me that RemoteException is aweful for
> same-JVM method calls?
Same VM calls that are always connected suck with RemoteExceptions ;)
--
Cheers,
Pete
-------------------------------------------------
"Sometimes its better to keep your mouth shut and
let people think your an idiot, than to open it
and remove all doubt."
-------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RemoteException (was Minutes from AvalonCon #1 )
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter,
>>I.e. My simple assertion is that an API should seemingly be as easy to use
>>remotely as locally. Glue is, RMI not.
>>
>
>keyword in that sentence - "seemingly" ;)
>
>If it seems as easy to use locally as it is remotely then you will have
>people treat it like a local object. This is *extremely* bad if you are
>trying to build a fault tolerant infrastrcutre. The more strongly typed and
>more easily that tools (ie compilers and whatnot) can tell me I am doing
>stupid things (like treating remote objects as locals) the better IMHO. With
>RMI as it is now you have to make a choice to program poorly. With the GLUE
>model you have to make a choice to program properly. Hence why I like RMIs
>model ;)
>
Could you at least agree with me that RemoteException is aweful for
same-JVM method calls?
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: RemoteException (was Minutes from AvalonCon #1 )
Posted by Peter Donald <do...@apache.org>.
On Sun, 28 Oct 2001 23:38, Paul Hammant wrote:
> I.e. My simple assertion is that an API should seemingly be as easy to use
> remotely as locally. Glue is, RMI not.
keyword in that sentence - "seemingly" ;)
If it seems as easy to use locally as it is remotely then you will have
people treat it like a local object. This is *extremely* bad if you are
trying to build a fault tolerant infrastrcutre. The more strongly typed and
more easily that tools (ie compilers and whatnot) can tell me I am doing
stupid things (like treating remote objects as locals) the better IMHO. With
RMI as it is now you have to make a choice to program poorly. With the GLUE
model you have to make a choice to program properly. Hence why I like RMIs
model ;)
--
Cheers,
Pete
--------------------------------
These aren't the droids you're
looking for. Move along.
--------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>