0

I have a WCF service that handles errors by implementing an IErrorHandler and attaching it to the ChannelDispatcher's ErrorHandlers.

The IErrorHandler has a method called

bool HandleError(Exception error);

Which I implement and simply logs the exception to my DB.

My problem is that some exceptions occur before the web service's method gets called.

I also have a MessageInspector that I attach to the EndpointDispatcher that logs the soap messages.

Now, assuming I have an sql error and get an unhandled exception on my MessageInspector, the HandleError method gets called twice with the same sql connection error exception.

The problem is that it happens once when the connection's status is opened and once when the connection's status is closed.

Also, the second method on the IErrorHandler:

void ProvideFault(Exception error, MessageVersion version, ref Message fault);

doesn't get called, and then the framework wraps my exception with a FaultException, without letting me format it.

Is there any reason why the IErrorHandler behaves that way? Is there any other module I need to implement in order to handle unhandled exceptions that occur as part of the request's pipeline? Why does the IErrorHandler get called when the connection is Closed?

Amir Popovich
  • 29,350
  • 9
  • 53
  • 99
  • In your implementation of HandleError, after it does the job, does it return false? – Ricardo Pontual Jun 23 '16 at 11:23
  • Yes, it returns false. When I fail on the message inspector, the ProvideFault method is not called and the HandleError is called twice. The client recieves the 500 error response before the second HandleError is called. When I fail as part of a service, The ProvideFault is called and the HandleError is called only once. I've checked that I don't add the ErrorHandler twice to the Clientdispatcher. – Amir Popovich Jun 23 '16 at 11:34
  • I asked because I remember helping someone with similar error, I think the issue was that ProvideFault did not hit, so we returned true in HandleError to force wcf error handler throw the error and get more info. Sorry but I don't remember exactly, but this can help in some way. – Ricardo Pontual Jun 23 '16 at 14:33
  • Thanks for the effort. My current "workaround" was to wrap the message inspector with a try-catch so it wouldn't crash my application with an unhandled exception and to secure the errorhandle with a if(state != Closed) condition. Anyway, I would like to hear about a better way to avoid this. – Amir Popovich Jun 23 '16 at 14:39

1 Answers1

0

We had a similar implementation of MessageInspector and wanted to know how long each request took. Consequently we did logging for both the incoming and outgoing messages. Perhaps this could be the case for your issue?

I'm not sure that the ProvideFault method is called when inside an extension behavior, however I was able to get it to fire from within the constructor of my restful WCF service. I think the 'workaround' of putting a try/catch in the inspector is a good approach.

Below are a couple of articles with implementation details on this topic:

IErrorHandler returning wrong message body when HTTP status code is 401 Unauthorized

How can I create custom XML namespace attributes when consuming a legacy SOAP service?

Also here is an article on how to do something similar in WebApi:

http://www.asp.net/web-api/overview/error-handling/web-api-global-error-handling

Community
  • 1
  • 1
John Meyer
  • 2,296
  • 1
  • 31
  • 39