I stumbled on a piece of SOAP today and this lead me to the discovery of a quite interesting Webservice response:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">   <soapenv:Body>     <soapenv:Fault>       <faultcode>soapenv:Server.userException</faultcode>       <faultstring>java.lang.NumberFormatException: For input string: &quot;3,14&quot;</faultstring>       <detail/>     </soapenv:Fault>   </soapenv:Body> </soapenv:Envelope>

Who had the idea to just forward the exception message to the Webservice? I bet they wouldn't like little Bobby Tables at all, too.

whoever:

I stumbled on a piece of SOAP today

 nothing wrong here.

bstorer:

whoever:

I stumbled on a piece of SOAP today

"What is this soap doing here?!  I don't bathe!"

And then he bent over to pick it up...

whoever:

I stumbled on a piece of SOAP today

APH:

So, it would be better to not provide information as to the cause of the error?

It would be better to provide a meaningful error message rather than forwarding a message like that. Parsing a custom message is a lot easier for client apps than parsing some random string you happened to get handed by the system. Plus if you ever migrate to another platform (or indeed, simply upgrade your current one, even minor versions in some cases), the message could completely change, meaning all the client apps suddenly have to know to expect something else in order to tell the user "you number was invalid".