views:

1226

answers:

2

I posted a question about using Messages versus Fault Exceptions to communicate business rules between services.

I was under the impression it carried overhead to throw this exception over the wire, but considering it's just a message that get serialized and deserialized, they were in fact one and the same.

But this got me thinking about throwing exceptions in general or more specifically throwing FaultExceptions.

Now within my service, if i use

throw new FaultException

to communicate a simple business rule like "Your account has not been activated", What overhead does this now carry? Is it the same overhead as throwing regular exceptions in .NET? or does WCF service handle these more efficiently with the use of Fault Contracts.

So in my user example, which is the optimal/preferred way to write my service method

option a

public void AuthenticateUser()
{
    throw new FaultException("Your account has not been activated");
}

option b

public AutheticateDto AutheticateUser()
{
     return new AutheticateDto() { 
          Success = false,
          Message = "Your account has not been activated"};
}
A: 

It's just like a normal exception, and uses the same wrapping code as a normal exception would to marshal into a fault, including unwinding the stack.

Like exceptions SOAP faults shouldn't, to my mind, be used for program flow, but to indicate errors.

blowdart
So you're a option B man??
WebDude
+2  A: 

Well... In general you shouldn't be throwing exceptions for expected conditions, or anything you expect to happen regularly. They are massively slower than doing normal methods. E.g., if you expect a file open to fail, don't throw a that exception up to your caller, pass the back a failure code, or provide a "CanOpenFile" method to do the test.

True, the message text itself isn't much, but a real exception is thrown and handled (possibly more expensively because of IIS), and then real exception is again thrown on the client when the fault is deserialized. So, double hit.

Honestly, if it is a low volume of calls, then you probably won't take any noticeable hit, but is not a good idea anyway. Who wants to put business logic in a catch block :)

Microsoft : Exceptions And Performance, & Alternatives

Developer Fusion: Performance, with example

Andrew Backer