Basically, on my own understanding with WCF Exception Shielding it is mostly beneficial on scenarios wherein you wouldn't want to display the exception message encountered from your WCF Operation Contract and replace it with a more
meaningful/high-level exception message that will then be passed to the client side application. Also, re-iterating from what have been
discussed in the documentation.
see explanation below.
Exception shielding helps prevent a Web service from disclosing information about the internal implementation of the service when an exception occurs. The following forces explain why you should use exception shielding:
- Exception details may contain clues that an attacker can use to exploit resources used by the system.
- Information related to anticipated exceptions needs to be returned to the client application.
- Exceptions that occur within a Web service should be logged to support troubleshooting.
Only exceptions that have been sanitized or are safe by design should be returned to the client application. Exceptions that are safe by design do not contain sensitive information in the exception message and they do not contain a detailed stack trace,
either of which might reveal sensitive information about the Web service's inner workings. You should use the Exception Shielding pattern to sanitize unsafe exceptions by replacing them with exceptions that are safe by design.
With regards to "But the samples I have seen are using throw new Fault exception<>
at the server side catch block", this is supposed to be in the Client side which is also as stated in the sample you have found.
We have a working sample for this, though it only focus on the implementation itself and may not provide you any real life scenarios you can use. But I bet you'll be able to think one once you have seen it working. Just send us an email if you want the sample.
Global Technology and Solutions