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