WCF - Faults / Exceptions versus Messages

Question

We're currently having a debate whether it's better to throw faults over a WCF channel, versus passing a message indicating the status or the response from a service.

Faults come with built-in support from WCF where by you can use the built-in error handlers and react accordingly. This, however, carries overhead as throwing exceptions in .NET can be quite costly.

Messages can contain the necessary information to determine what happened with your service call without the overhead of throwing an exception. It does however need several lines of repetitive code to analyze the message and determine actions following its contents.

We took a stab at creating a generic message object we could utilize in our services, and this is what we came up with:

public class ReturnItemDTO<T>
{
    [DataMember]
    public bool Success { get; set; }

    [DataMember]
    public string ErrorMessage { get; set; }

    [DataMember]
    public T Item { get; set; }
}

If all my service calls return this item, I can consistently check the "Success" property to determine if all went well. I then have an error message string in the event indicating something went wrong, and a generic item containing a Dto if needed.

The exception information will have to be logged away to a central logging service and not passed back from the service.

Thoughts? Comments? Ideas? Suggestions?

Some further clarification on my question

An issue I'm having with fault contracts is communicating business rules.

Like, if someone logs in, and their account is locked, how do I communicate that? Their login obviously fails, but it fails due to the reason "Account Locked".

So do I:

A) use a boolean, throw Fault with message account locked

B) return AuthenticatedDTO with relevant information

Paul van Brenk · Accepted Answer · 2008-09-17T09:58:24.193

32

This however carries overhead as throwing exceptions in .NET can be quite costly.

You're serializing and de-serializing objects to XML and sending them over a slow network.. the overhead from throwing an exception is negligable compared to that.

I usually stick to throwing exceptions, since they clearly communicate something went wrong and all webservice toolkits have a good way of handling them.

In your sample I would throw an UnauthorizedAccessException with the message "Account Locked".

Clarification: The .NET wcf services translate exceptions to FaultContracts by default, but you can change this behaviour. MSDN:Specifying and Handling Faults in Contracts and Services

edited Sep 17 '08 at 09:58

answered Sep 17 '08 at 09:09

Paul van Brenk

7,450
2
33
38

I disagree. Since WCF is supposed to be language-agnostic (in some form, at least) you can't guarantee that passing an Exception object down the wire won't cause buig problems for e.g. Java clients. The FaultContract object type can ensure interoperability since it is part of the OASIS specs. – ZombieSheep Sep 17 '08 at 09:39
4

.NET translates exceptions to Fault contracts. See the link I added to my answer. – Paul van Brenk Sep 17 '08 at 09:59
I was always under the impression that throwing an exception carried unnecesary overhead. From your post I seem to have been sadly misguided. Before i mark this post as the asnwer, I want to get some more opinions. But considering your input, seems fault contract is the better option – WebDude Sep 17 '08 at 10:53
This is an excellent answer. Returning a fault keeps intentions clear and also makes it easy to standardize error handling practices across a team of developers (just throw a darn exception). If a service is generating so many faults that performance is a consideration, there is likely a major problem with the code (either exceptions are being used for control-flow, which is a very bad practice, or there is a serious bug). – DVK Jul 06 '17 at 20:56

score 6 · Answer 2 · answered Sep 25 '12 at 05:39

If you think about calling the service like calling any other method, it may help put things into perspective. Imagine if every method you called returned a status, and you it was up to you to check whether it was true or false. It would get quite tedious.

result = CallMethod();
if (!result.Success) handleError();

result = CallAnotherMethod();
if (!result.Success) handleError();

result = NotAgain();
if (!result.Success) handleError();

This is one of the strong points of a structured error handling system, is that you can separate your actual logic from your error handling. You don't have to keep checking, you know it was a success if no exception was thrown.

try 
{
    CallMethod();
    CallAnotherMethod();
    NotAgain();
}
catch (Exception e)
{
    handleError();
}

At the same time, by returning a result you're putting more responsibility on the client. You may well know to check for errors in the result object, but John Doe comes in and just starts calling away to your service, oblivious that anything is wrong because an exception is not thrown. This is another great strength of exceptions is that they give us a good slap in the face when something is wrong and needs to be taken care of.

score 0 · Answer 3 · answered Sep 17 '08 at 09:13

I would seriously consider using the FaultContract and FaultException objects to get around this. This will allow you to pass meaningful error messages back to the client, but only when a fault condition occurs.

Unfortunately, I'm in a training course at the moment, so can't write up a full answer, but as luck would have it I'm learning about exception management in WCF applications. I'll post back tonight with more information. (Sorry it's a feeble answer)

WCF - Faults / Exceptions versus Messages

3 Answers3

Linked

Related