views:

39

answers:

4

I have an ASMX web service and I have a couple of methods that in their original implementation were of return type bool.

What would the proper way of returning an error to the client? Currently they just return false. Is there a way to return a more complex type that would inform the client of an issue such as a null value passed for a required parameter?

A: 

If you are dealing with a .NET service to a .NET client you can pass this data in an exception, simply throw it up in your method being invoked in the service. If you are dealing with different technologies you can still do it to some degree by throwing an exception within the WS method, however you don;t get the interwoven behavior as much as you do using WCF/.NET or Axis2/Java on both sides for instance.

Aaron
-1: sorry, no, this will not work in ASMX web services.
John Saunders
@John So this is not accurate? http://msdn.microsoft.com/en-us/library/cc304761.aspx My understanding is that he wants to pass back reasons, ie..codes...while he states "complex type" the example doesn't seem to be more then error codes/strings
Aaron
@Aaron: an unhandled exception will generate a SoapException which will be sent to the client as a SOAP Fault. There will be no useful information in that fault, and the client will have no reason to believe that you can ever send him a fault. In fact, a WCF client of such a service will throw an fatal exception in that case.
John Saunders
@John Fair enough, while the majority of my use within the WS realm has been internal across technologies, ie...SL 2/3 client consuming an Axis2 WS. It was painful to say the least. We had to come up with varying ways to try and get the inofrmaiton we were seeking...this provides light into the SL2 WS pain...http://eugeneos.blogspot.com/2008/09/faults-and-exceptions-when-using-web.html
Aaron
@Aaron: I don't see any pain there. Exceptions should not propagate out of a service. Period. If the service wishes to expose a fault, that should be a deliberate decision. WCF supports this. ASMX doesn't, but that shouldn't matter much, since nobody should be doing any new development using ASMX.
John Saunders
@John This had to do with an SL2 client. Couple that with the fact that the actual service was an Axis2 service and it was worse. The fault was exposed via Fiddler, yet due to the sandboxed nature of SL at that point in time the data could not get to the client unless we jumped out of the SL application into JS. What WCF/ASMX do is fine and dandy but when the WS and the client are on differing technologies pain surfaces.
Aaron
@Aaron: I don't understand why you should have had a problem. Are you saying that SL2 could not handle SOAP Faults at all? The fact it was an Axis service should not have been relevant. Likely, whatever problem you had would have been identical given an equivalent WCF service. For instance, if the Axis2 service did not expose its faults in the WSDL, then problems were going to happen no matter what type of client you used.
John Saunders
@John that is correct. SL2 could not handle SOAP faults. In addition a workaround was devised by the WS team at MS but ONLY if you were using WCF, which we were not so we were still crippled.
Aaron
@John If you are truly interested I can dig up information as I began a dialog via email as well with folks on the MS side (previous employer, no longer access to emails), however it was painful to say the least...and to be honest part of it was the bleeding edge of SL, so I can live with it.
Aaron
@Aaron: Thanks, but if it's any tougher than posting a link, don't bother.
John Saunders
A: 

Certainly, you can create an object that has a bool if it passed or not and a string that exposes a message. Consumers of the web service will have access to that object just as they would the original bool.

Chris Conway
A: 

I think you're looking for SoapException Class

Oren A
-1: Oren, what will he do when he _finds_ the SoapException class?
John Saunders
@John, throw it?!
Oren A
@Oren: and then what? Read his question again.
John Saunders
+2  A: 
  • The way to do this with SOAP is to return a SOAP Fault message.
  • Unfortunately, ASMX web services don't properly support SOAP Fault messages.

The good news is that you should be using WCF for all development of web service clients and servers, and that WCF fully supports SOAP Faults.

Remember that, whatever you do, your clients will need to know that you are doing it. One of the issues with ASMX support of faults is that information on which operation sends which fault is not emitted into the WSDL, so a client will have no idea that you are returning faults.

John Saunders
Thanks, John. I will be reimplementing this in WCF, then. Any suggestions on resources that cn get me up and running fast? I've said it 100 times on this site. I'm not a dev - I'm more a production DBA.
Robert Kaucher
http://stackoverflow.com/tags/wcf/info
John Saunders
@Robert: may i ask what made you begin your work with web services using ASMX?
John Saunders
It was there. That's about it. I have used WCF with a few Silverlight projects, but I did not write the service myself. I happened accross an ASMX tutorial that I thought was helpful. And I used it. We originally published this as an End Point in SQL Server but there were authentication issues that we could not resolve.
Robert Kaucher
@Robert: can you post a link to that tutorial? I'd like to see what can be done to prevent others like you from taking an old tutorial as the reason to use the wrong technology.
John Saunders