In one of the discussions  on the MSDN Architecture Forum someone  mentioned that when a service invocation results in  an exception his company standard is to:

• Log the error before exiting the service

• Create a new SOAP error (exception) with minimal info ("The requested service failed") and that error includes (innerException) the original error (This way, if someone receives my error and they are not familiar with my errors - they will get a simple soap error. If they are familiar with my error, they will have the ability to inspect it further)

I think this is this is the very distinct  anti-pattern of how to do SOA i

Lets look at few reasons why:

1. Log the error - that is fine and everything - maybe it'll help during the post mortem, but the operations people should also be notified somehow. Otherwise you have a dead service there and no one knows

2. "exiting the service"  - Services shouldn't fail - a failed service can mean a lost business opportunity.   When  you can't service the requests, you should at least be able to maintain the "well know end-point" up and running and let everyone know that the service is, well, "out of service - be back in XYZ". The preferable solution is to still  be able to queue incoming  requests and handle them later (this may not be possible if part of the policy (or SLA) for the service is to react within few seconds, but again, in many other circumstances it is very plausible.

3. SOAP Exception - why through a SOAP exception - the protocol/communication worked fine...

4. "...(innerException) the original error" - do not expose internal implementation out side of the service - only what's in the contract - in other words don't, just don't bubble exceptions out of your service.

It is very easy to make, what seems like, a small concession on the purity of your service, but your SOA concept and loose coupling specifically can deteriorate very rapidly on even the smallest compromises