call or reply toward unregistered client

Mark Taylor m.b.taylor at bristol.ac.uk
Mon Feb 16 05:23:46 PST 2009


On Thu, 12 Feb 2009, Yohann Granet wrote:

> Hi,
> 
> I work with the JSAMP framework (0.3) to implement a package manager in Java.
> 
> During my tests I found out that a "call" or a "reply" toward an unregistered
> client throws an Exception
> (the class involved is org.astrogrid.samp.xmlrpc.XmlRpcHubConnection)
> 
> here, the trace for a "call":
> org.astrogrid.samp.client.SampException: -9999:
> org.astrogrid.samp.hub.HubServiceException: Client c6 is no longer registered
>    at
> org.astrogrid.samp.xmlrpc.XmlRpcHubConnection.rawExec(XmlRpcHubConnection.java:187)
>    at
> org.astrogrid.samp.xmlrpc.XmlRpcHubConnection.exec(XmlRpcHubConnection.java:170)
>    at
> org.astrogrid.samp.xmlrpc.XmlRpcHubConnection.call(XmlRpcHubConnection.java:135)
>    ...
> 
> and here for a "reply":
> org.astrogrid.samp.client.SampException: -9999:
> org.astrogrid.samp.hub.HubServiceException: Client c5 is no longer registered
>    at
> org.astrogrid.samp.xmlrpc.XmlRpcHubConnection.rawExec(XmlRpcHubConnection.java:187)
>    at
> org.astrogrid.samp.xmlrpc.XmlRpcHubConnection.exec(XmlRpcHubConnection.java:170)
>    at
> org.astrogrid.samp.xmlrpc.XmlRpcHubConnection.reply(XmlRpcHubConnection.java:153)
>    ...
> 
> I think that an attempt to call (or reply) an absent client shouldn't cause an
> Exception launching...
> Exceptions are not there to manage particular (but "normal") cases

Hi Yohann,

I admit that what to do in this case it not explicitly defined in the
SAMP standard, though Section 3.13 does say:

   In the case of failed calls ... for instance syntactically invalid 
   parameters or communications failures, hubs and clients SHOULD use 
   the usual error reporting mechanisms of the transport protocol in use.

However, I think that the JSAMP hub signalling an error if the target
client is no longer registered is a reasonable thing for it to do
(when the client toolkit receives this error it throws it as an 
exception).  This could be made more explicit by adding the following
clause to the above paragraph:

   ... for instance syntactically invalid parameters, communication
   failures, or unregistered target clients, ...

> I think that, instead of an Exception, a "null" returned or a specific message
> would be preferable

It's useful to know that your call or reply has not been accepted.
It's true that in the case of call() a null string could be returned 
as a special case, but reply() has no return value, so you couldn't
do the same thing there.  In any case the benefit of generating an
error is that the error can contain text saying what's gone wrong.
You can always catch and ignore the exception if you don't care.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/



More information about the apps-samp mailing list