CODEWITHSUNDEEP
c#wcfservice
Lee.J.Baxter
Lee.J.Baxter

Reputation: 555

How should I go about handling exceptions thrown within a WCF service?

I've created a service that listens out for commands to launch executables, which is hosted via a WPF application with a list-box that displays messages to the user.

The thing is, the service could potentially throw exceptions, which I want to catch and display in the list-box; the only problem with this is that I'm not sure how to go about catching these exceptions, as the service is, of course, run from a ServiceHost.

The best thing I can really think of doing, without tying the service to the UI (I want to avoid this so that I can re-use it in, say a console application), is to add an event to the service that's invoked when an exception is thrown, where I'll pass the exception into the handler.

My service is created outside of the ServiceHost anyway (as a singleton object), as it has an event for when an executable is launched.

Is this the best way to go about this, and if not, what is?

Upvotes: 1

Views: 339

Answers (1)

tom redfern
tom redfern

Reputation: 31750

The thing is, the service could potentially throw exceptions, which I want to catch and display in the list-box

I think the safest thing to do here would be for your service operation to log exceptions, either to a file or database.

Your WPF app would then need some mechanism to consume this log.

This keeps your service and the hosting container completely decoupled.

However, if you do want to couple your WPF app and ServiceHost together, look at the WPF/WCF hosting sample on codeplex. There is communication going on between the ServiceHost and the host application there.

is there any particular reason to consider an event as an unsafe method of passing thrown exceptions to the hosting container?

Not unsafe as such. I guess it's about complexity. In effect you have two components masquerading as a single component. Even though one component is acting as a hosting container for the other, they should still be considered separate.

If an exception is thrown from inside a service operation, the handling of the exception should be internal to the service. This is one of the principals of SOA, that services should be autonomous.

If there are side effects to the exception that other components are interested in, then these can be communicated to the outside world in the form of an event.

I guess the point here is should the event simply contain the exception? The exception is meaningful inside the service boundary, but what in fact does the exception mean? There may in-fact be many different reasons you will get an exception, in which case you should create different event types for each failure reason, some of which may not be appropriate to expose outside of the service.

However, I am probably overthinking this. WPF is a valid, Microsoft-supported hosting container for WCF, and the scenario you are implementing is probably quite common.

Sorry for the rambling - I'm trying to arrive at something making me generally uneasy about your solution, but I'm not doing a great job of getting there...

Upvotes: 1

Related Questions