According to the documentation,
IErrorHandler enables you to explicitly control the SOAP fault generated
It's not for changing the actual return value of the service.
If I understand correctly, your service already returns a string. If an error occurs, you want your service to return a particular string.
In its simplest form, this would look like this:
public string YourServiceMethod(int someInput)
{
try
{
// Do whatever the method does
}
catch(Exception ex)
{
// Log the exception, probably?
return "This is the specific error message I want to return."
}
}
If you want to avoid writing that same code in every method, one way to accomplish that is using an interceptor, such as with Castle Windsor's dependency injection container.
That means modifying the whole WCF service to use Windsor (or some similar DI framework) but it's worth it for lots of other reasons. I use it for every WCF service I write. Here's a tutorial on how to add Windsor to your WCF service in five minutes.
Then you would write a class called an interceptor. It might look something like this:
public class ErrorMessageInterceptor : IInterceptor
{
public void Intercept(IInvocation invocation)
{
try
{
invocation.Proceed();
}
catch (Exception ex)
{
// log your exception
invocation.ReturnValue = "Your specific error message.";
}
}
}
Then, when you register your service with the container you would do this:
container.Register(
Component.For<IInterceptor>().ImplementedBy<ServerLogInterceptor>()
.Named("ErrorMessageInterceptor"));
container.Register(Component.For<IYourService,YourService>()
.Interceptors("ErrorMessageInterceptor"));
where IYourService
is your service interface and YourService
is the actual service class.
This means that every time an instance of YourService
is activated, an instance of ErrorMessageInterceptor
is created. All calls to the service's method are "intercepted" by the interceptor's Intercept
method. It's essentially putting a try/catch
around the method call without directly adding it into the original method.
If you needed to you could be more specific. For example, your interceptor could check invocation.Method.ReturnType
to see if the method returns a string, and only add your error message then.
You can do some great stuff with interceptors. A scenario like this where you're trying to something small is a great opportunity to try working with them. If you haven't used DI with WCF before it looks weird, but likewise once you try it you might find that it's a very useful pattern.