views:

1274

answers:

2

I have a web service method where I would like to throw some custom exceptions e.g. SomeException, SomeOtherException etc which the web service would then turn into a SOAP fault which the client would be able to handle. In Java I can have wsdl:fault elements within the wsdl:operation element in the WSDL. It appears it .NET that this is not catered for and that there is no way of putting attributes on a WebMethod to show what SOAP faults may occur.

If I create a Java web service which has wsdl:fault elements and add a web reference to a .NET project I would have expected the wsdl:fault elements to cause appropriately named exceptions to be created just as the other entities are created, this however does not seem to be the case.

Is it the case that wsdl:fault elements in a WSDL are completly ignored by .NET? They are part of the WSDL specification defined at http://www.w3.org/TR/wsdl so this wasn't the behaviour I was expecting.

If this is the case possible work arounds might be returning a result object which contains a success/failure boolean value and an error message/enum. Or by using SoapExceptions. If I choose to use SoapExceptions I am then putting the emphesis on the user of my web service to handle these and deserialize it properly. Both of these don't seem a great way of handling this and add extra problems and code to workaround this.

Any advice?

+1  A: 

Since you ask for .net 2.0 i guess you know that this is "fixed" in WCF where you can add the attribute [FaultContract(typeof(YourCustomException))].

The "normal" way this was done in 2.0 is as you says, add a Response message with a success-boolean, Result and a Error property.

You can typically see how this is done in EntLib.

ThorHalvor
Yeah I am stuck with .NET 2, I did know about that in WCF and was hoping there was some way to implement [FaultContract(typeof(YourCustomException))] in a SOAP web service in .NET 2 that I was overlooking but looks like thats not the case.
Martin
Looks like the best way to handle this will be to follow the pattern of "success-boolean, Result and a Error property". Thanks.
Martin
+2  A: 

ASMX web services did not support the wsdl:fault element, either on the client or the server. They never will.

As ThorHalvor has said, the bug fix for this is called "WCF".

I have successfully hand-written a WSDL that includes wsdl:fault elements, then returned those faults through an ASMX web service by including the fault message as the Detail property of a SoapException. Java and WCF clients then properly saw this as an exception of the appropriate kind.

John Saunders
I have looked at hand-writing the WSDL so that other clients that do work with wsdl:fault would be able to pick these up. But it does leave people implementing using .NET without anyway of working out what is happening in terms of exceptions unless they read through the WDSL themselves.
Martin
Useful to know that ASMX web services do not support the fault element in the WSDL. I was aware this wouldn't be a problem if I was using WCF but I cannot do this at the moment so was hoping for a solution in .NET 2 as in the title.
Martin
No, if your service sends a proper fault, by filling in the Detail property of the SoapException, then even a .NET 2.0 client will receive a SoapException with the Detail property filled in. Just not a separate exception for each fault.
John Saunders
There are reasons to upgrade to WCF...
John Saunders
Yeah I know there are reasons to upgrade but I cannot use it in this project, not my decision. Doing this with the SoapException requires that the client then (if they .NET are pre-WCF) has to work out what to do with the detail XML they are returned. Get the ExceptionType from it. This is right?
Martin
Yes. That's correct. I recommend an XML format that makes the type of exception manifest. I made the root element unique, per "exception". That helped.
John Saunders
Lol, somebody flagged this answer as offensive. Maybe someone from the web service team at MS?
Will