Best practice to handle WCF service errors?

I am coding some kind of a WCF service. most exceptions are caught in the BL implementation and handled there. Each of my API's return type is a class (named - "result") containing error code, error message and success boolean.

When exceptions are handled, this class is updated accordingly and in the end is sent back to the client. Some of the exceptions are off-course, unhandled. Currently, I am wrapping each of my BL calls from the service layer with a generic try-catch so I can catch every unhandled exception and create a generic "result" class with a generic failure mes开发者_运维百科sage, error code and success=false.

Is it a good way to handle exceptions or should I let unhandled exception to be thrown by the service to the client? You can assume that the client can't use the data from the exception so it won't benefit from the extra information contained in the exception.

Check out Exception Shielding.

This is a process where exceptions raised by the service, are mapped to fault contracts according to rules you specify in a configuration file. This saves a lot of donkey work with try/catch blocks.

Here is one post to help you out:

In general though - faults will fall into 3 categories:

1) Client error - the client has tried to do something not permissable, so it needs to know about it. E.g. Failed to set a mandatory field. - Return specific message explaining fault.

2) Business error that doesn't affect the client. An error that is considered normal operation, e.g. Payment Authorization check failure. Either hide from client completely, or return some message: "Error performing request: Please try again later..."

3) System error - Unexpected - not normal operation: Replace with generic message: "System Error: Call Support"

In all cases though, the key thing is you remove the stack trace, especially if it's a public facing service.

With shielding you would have 3 Fault Contracts covering the above scenarios, and set the text appropriately in the Shielding configuration.

Be advised, you generally want shielding turned off during development as it makes it a right pain to debug the system!

I differ with the others. I think that in the same way HTTP methods GET, POST, PUT, DELETE thereby support CRUD operations, HTTP response codes 200, 500, etc., support success/fail and this is, in my opinion, appropriate to make use of. A 500 result still has an HTTP response body, and such a body is fully readable (so long as IIS isn't spitting out HTML; you have control over this). Meanwhile, the XML protocol implementations as with Microsoft SOAP from WCF already wrap exceptions with a faulting protocol.

If you're going to throw exceptions, throw them. Just document them while doing so, so that the consumers can plan accordingly.

I think both approaches are viable.

I personally prefer not throwing exceptions over WCF, so that the client can easily distinguish between error in server-side processing and connectivity/protocol issue: in the first case the response will indicate the failure, and in the second case exception will be thrown.

Personally I wouldn't expose the unhandled exceptions and propagate them to the client. I would define those exceptions the client might be interested in and only propagate those. Exceptions not directly related to what the clients want to do (ArgumentException could set reason to "CustomerId cannot be more than 20 chars" etc.) I'd deal with in the service and only indicate that some sort of internal server error has occurred on the service side which broke the execution and meant that the operation the client tried to run failed to complete. This I would do because the client can't really take any action based on internal server errors. They can fix their inparams in the case of an ArgumentException being thrown by validating the parameters again and retry the operation.

Not sure if this is really what you're asking, but hope it gives you some ideas at least.

If you let unhandled exceptions out of your WCF service, this may have undesirable effects such as communication channel being in faulted state where in a sessionful scenario, client can no longer use the same client proxy instance but is forced to create a new one and start a new session. In general, I think it is good to have control over the errors that surface out of your WCF service and provide clients helpful information. Take a look at IErrorHandler.This interface gives you control over the SOAP fault generated, unhandled exceptions, and allows you to do extra tasks like logging, and lets you decide whether you want to keep the session or not in case of a sessionful binding. You add your custom error handler via WCF extensibility such as service, endpoint, contract, operation behaviors.

Note that IErrorHandler is called before sending a response message. So there is still a chance of an unhandled exception occurring down in the channel stack during serialization, encoding, etc.