[quoted text, click to view] > [...] Based on what you said, it seems normal, and we
> need to create those custom exception classes manually if we want the
> custom exception class. Correct?
Yes you are correct, but there still remains the problem of actually catching
the SoapException and rethrowing it as something more meaningful.
When the response is received from the webservice, the SoapHttpClientProtocol
class (a base class for proxies) parses the message and when it finds the
fault element it turns it into a SoapException and initializes the instance
with the values from the fault element (fault code and subcode, details node
etc). If you look into the autogenerated Visual Studio proxy you will notice
that each WS operation is called using the following code:
object[] results = this.Invoke("OperationName", new object[] {operationNameRequestObject});
You could of course mess with the proxy, surround all those calls with try..catch
block and provide your own logic to turn the SoapException into a custom
one. This is of course a really bad approach as
1) you would have to repeat this whenever the proxy is regenerated
2) depending on the amount of operations exposed by the service this could
be many lines of custom code to write
Instead what I would do would be to create your own base proxy class MyHttpClientProtocol
deriving from SoapHttpClientProtocol and override the Invoke method:
protected override object[] Invoke(string methodName, object[] parameters)
{
try
{
base.Invoke(methodName, parameters);
} catch (SoapException ex)
{
throw GetCustomException(ex);
}
}
where GetCustomException would provide an instance of your own exception
based on the fault code and subcode. I believe you could point wsdl.exe to
this use this class as a base class for the proxy it generates. This probably
is, at least conceptually, the easiest approach.
A better approach however would be to leverage the extensibility of the framework
and to use the soap extensions mechanism (
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwebservicesprotocolssoapextensionclasstopic.asp).
Such extension would probably parse the response message to see if it was
a fault and deserialize it into an instanse of your custom exception.
You should of course make the decision based on on your needs and the time
you have to implement the client application. I hope this will help you to
make up your mind.
Best regards,
Robert Wilczynski
wilczynski.robert@gmail.com
[quoted text, click to view] > Robert Wilczynski wrote:
>
>> Hi,
>>
>> Provided that you are using SOAP to access the web service, a
>> SoapException will be thrown on the client. I believe (yet I may not
>> be entirely correct) that WCF (aka Indigo) will generate custom
>> classes for fault elements and now comes with the GoLive license so
>> this might be the way go if you really need what you have described.
>> If not then you could just provide a generic SoapException handling
>> mechanism on the client.
>>
>> Best regards,
>> Robert Wilczynski
> Rob:
>
> I am using Visual Studio .NET 2003 Enterprise Architect, and when I
> run wsdl.exe or add web reference, the auto-generated code doesn't
> generate any custom exception classes that correspond to <wsdl:fault>
> element in WSDL file. Based on what you said, it seems normal, and we
> need to create those custom exception classes manually if we want the
> custom exception class. Correct?
>
> I tried to download Indigo from
>
http://msdn.microsoft.com/webservices/indigo/, but it always say the
> download site is unavailable now.
>