Server side exceptions

[Tanya Brethour <br...@ncsa.uiuc.edu>]

Hello! I have a question about exception handling from the server.

As far as I can tell, when the client calls execute, and when an exception
is generated by the server, a new exception is thrown in the client
(XmlRpcException.java). However, the information as to what
exception/error occurred in the original server seems to be lost. Of
course the message strings are preserved and its possible to parse the
messages to see what error occurred in the server originally... but isn't
there a better way?

My question is, with the addition of exception chaining in Java 1.4, I
think you are capable of setting the "cause" object to be whatever caused
the new exception to happen. Can this be done in XmlRpcException as well
to capture what exception was thrown in the server?

I'm a bit new to this concept of chaining of exceptions... so please
forgive me if I am misunderstanding anything. What my ultimate goal is for
my xml-rpc client to be able to know what exception was thrown in the
server and then the client responds appropriately. But right now, I can
catch the XmlRpcException, but calling getCause() obviously returns a null
value. I thought getCause() should be setup to get the original
exception. 

I hope I am making sense :) 

I look forward to hearing any advice or lectures about how chaining really
works ;) 

TIA!

-Tanya

Re: Server side exceptions

[Tino Wildenhain <ti...@wildenhain.de>]

Hi,

Pierre-Yves Varoux schrieb:
>>>And why not re-generating exception by parsing the message exception ?
> 
> 
>>Because it almost seems like a hack. I just thought there was probably a
>>more proper way to do it. But maybe there isn't :)
> 
> 
> Yes... Exceptions are a java mechanism and xmlrpc must be interoperant (with
> fault
> codes).

Not precise java mechanism only. Exceptions are known in every good
OOP-language. The problem is:

a) not all XMLRPC implementations run on OOP languages
b) not all these languages, if OOP have Exceptions
c) not all wich have Excptions can have subclasses of them
d) if all the above, how should the client know the
    type of the exception based on a name, when it does
    not share the implementation (same base classes for Exceptions)
    with the host?

The only solution I would see so far is to implement a common
set of Exception types for which the server is responsible
to identyfy and map to and a matching implementation on client
side.

Regards
Tino

Re: Server side exceptions

[Ryan Hoegg <rh...@isisnetworks.net>]

Tanya Brethour wrote:

>>>>And why not re-generating exception by parsing the message exception ?
>>>>        
>>>>
>>>Because it almost seems like a hack. I just thought there was probably a
>>>more proper way to do it. But maybe there isn't :)
>>>      
>>>
>>Yes... Exceptions are a java mechanism and xmlrpc must be interoperant (with
>>fault
>>codes).
>>    
>>
>
>So, how exactly do I specify the fault codes? I use the server to generate
>the methodReponse bodies... and there doesn't seem to be a way to control
>the fault code part. 
>
>
>Thanks,
>Tanya
>
>  
>
Just throw a new XmlRpcException(int code, String message) from your 
handler.

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Re: AW: Server side exceptions

[Tanya Brethour <br...@ncsa.uiuc.edu>]

> As you can see in XmlRpcResponseProcessor in the method processException()
> 
>         // Retrieve XmlRpcException error code(if possible).
>         int code = x instanceof XmlRpcException ?
>                ((XmlRpcException) x).code : 0;
> 
> you can set your own fault codes by throwing Exceptions derived from
> XmlRpcException.

Thanks to all for the help. I appreciate you taking the time to help a
XML-RPC newbie.

:)

-Tanya

AW: Server side exceptions

[Christoph Mattler <ch...@imail.de>]

I solved this problem for me by using my own exception derived from
XmlRpcException.

public class XmlRpcServerException extends XmlRpcException
{
	public XmlRpcServerException(int code, String message)
	{
		super(code, message);
	}

	public String toString()
	{
		if (getCause() != null)
			return getMessage() + " => " + getCause().toString();
		else
			return super.toString();
	}
}

As you can see in XmlRpcResponseProcessor in the method processException()

        // Retrieve XmlRpcException error code(if possible).
        int code = x instanceof XmlRpcException ?
               ((XmlRpcException) x).code : 0;

you can set your own fault codes by throwing Exceptions derived from
XmlRpcException.



-----Ursprungliche Nachricht-----
Von: Tanya Brethour [mailto:brethour@ncsa.uiuc.edu]
Gesendet: Donnerstag, 30. Oktober 2003 17:20
An: xmlrpc-user@ws.apache.org
Betreff: RE: Server side exceptions



> >> And why not re-generating exception by parsing the message exception ?
>
> >Because it almost seems like a hack. I just thought there was probably a
> >more proper way to do it. But maybe there isn't :)
>
> Yes... Exceptions are a java mechanism and xmlrpc must be interoperant
(with
> fault
> codes).

So, how exactly do I specify the fault codes? I use the server to generate
the methodReponse bodies... and there doesn't seem to be a way to control
the fault code part.


Thanks,
Tanya

RE: Server side exceptions

[Tanya Brethour <br...@ncsa.uiuc.edu>]

> >> And why not re-generating exception by parsing the message exception ?
> 
> >Because it almost seems like a hack. I just thought there was probably a
> >more proper way to do it. But maybe there isn't :)
> 
> Yes... Exceptions are a java mechanism and xmlrpc must be interoperant (with
> fault
> codes).

So, how exactly do I specify the fault codes? I use the server to generate
the methodReponse bodies... and there doesn't seem to be a way to control
the fault code part. 


Thanks,
Tanya

RE: Server side exceptions

[Pierre-Yves Varoux <pi...@add-online.fr>]

>> And why not re-generating exception by parsing the message exception ?

>Because it almost seems like a hack. I just thought there was probably a
>more proper way to do it. But maybe there isn't :)

Yes... Exceptions are a java mechanism and xmlrpc must be interoperant (with
fault
codes).

Pierre-Yves.

RE: Server side exceptions

[Tanya Brethour <br...@ncsa.uiuc.edu>]

> And why not re-generating exception by parsing the message exception ?

Because it almost seems like a hack. I just thought there was probably a
more proper way to do it. But maybe there isn't :)

-Tanya

RE: Server side exceptions

[Pierre-Yves Varoux <pi...@add-online.fr>]

And why not re-generating exception by parsing the message exception ?


...
} catch (XmlRpcException xre) {

String s = xre.getMessage();
s = s.substring(s.indexOf("test.xmlrpc.exception"));
int deuxPoints = s.indexOf(":");
String strException = s.substring(0, deuxPoints);
String message = s.substring(deuxPoints);

Class cls = Class.forName(strException);
Constructor con = cls.getConstructor(new Class[]{String.class});
Exception e = (Exception)con.newInstance(new Object[]{message});
throw e;
...

Pierre-Yves VAROUX.

Re: Server side exceptions

[Tanya Brethour <br...@ncsa.uiuc.edu>]

> Well, XML-RPC has no notion of exception chaining.  For that specific 
> behavior, I'd look into RMI.

Ok. I'd like to use XML-RPC so... I'll explore the option you suggested
below.

> In XML-RPC, I think the standard way to do this would be to create fault 
> codes for each expected exception.  You can then branch on that on the 
> client side.

Ok. So from what I have read on XML-RPC there are supposed to be some list
of predefined exceptions (although I am having difficulty find that), and
then I guess you can always create your own. 

So, right now I am creating a WebServer, and then calling addHandler()
with a java object. Then it looks for public methods when doing an
execute. There doesn't seem to be a way to set the fault code with this
method.

I'm guessing the only way to implement my own fault codes is to pass the
WebServer a XmlRpcServer an object that implements interface
org.apache.xmlrpc.XmlRpcHandler. Correct?

Thanks for the reply. And thanks for being patient with a newbie :)

-Tanya

Re: Server side exceptions

[Ryan Hoegg <rh...@isisnetworks.net>]

Well, XML-RPC has no notion of exception chaining.  For that specific 
behavior, I'd look into RMI.

In XML-RPC, I think the standard way to do this would be to create fault 
codes for each expected exception.  You can then branch on that on the 
client side.

Good luck!

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net

Tanya Brethour wrote:

>Hello! I have a question about exception handling from the server.
>
>As far as I can tell, when the client calls execute, and when an exception
>is generated by the server, a new exception is thrown in the client
>(XmlRpcException.java). However, the information as to what
>exception/error occurred in the original server seems to be lost. Of
>course the message strings are preserved and its possible to parse the
>messages to see what error occurred in the server originally... but isn't
>there a better way?
>
>My question is, with the addition of exception chaining in Java 1.4, I
>think you are capable of setting the "cause" object to be whatever caused
>the new exception to happen. Can this be done in XmlRpcException as well
>to capture what exception was thrown in the server?
>
>I'm a bit new to this concept of chaining of exceptions... so please
>forgive me if I am misunderstanding anything. What my ultimate goal is for
>my xml-rpc client to be able to know what exception was thrown in the
>server and then the client responds appropriately. But right now, I can
>catch the XmlRpcException, but calling getCause() obviously returns a null
>value. I thought getCause() should be setup to get the original
>exception. 
>
>I hope I am making sense :) 
>
>I look forward to hearing any advice or lectures about how chaining really
>works ;) 
>
>TIA!
>
>-Tanya
>
>  
>