I've been looking for a simple way to communicate exception information from a web service to its clients. The SOAP spec defines a reasonable way to do this, but the programming model (SoapException) really makes it painful. Here's what I'm trying to model:
try {
int value = LookupSomething("some index");
}
catch (ItemNotFoundException) {
// certain special exceptions I can recover from
}
This is a very common programming construct - in certain cases we can easily recover from an exception, so we create special exception classes (if they don't already exist) to signal these situations. In a web service, you might use the faultstring to signal these sorts of things (the faultcode is controlled by the SOAP spec, so that's not something I want to customize). Well, to do this, you use SoapException, and you can set the SOAP faultstring via the Message property:
throw new SoapException("ItemNotFound", ...);
and on the client, you'd expect to be able to read the faultstring:
catch (SoapException x) {
if ("ItemNotFound" == x.FaultString)
recover();
else throw;
}
Here's the problem: there is no FaultString property on SoapException. And if you read the Message property, you'll find your faultstring interspersed with a load of other crap that you don't care about:
System.Web.Services.Protocols.SoapException: ItemNotFound at Foo.LookupSomething(String index) in foo.cs:line 80
Well, that's just peachy. So I guess I can use the detail field to supply a DOM with details about the exception, and the client SoapException won't futz around with that, but my goodness, that's way overkill for what I want.
Am I missing something, or did Microsoft simply not consider the client exception programming model? Did they just assume we'd implement all our exception handling blocks with a message box?