You read it right. There is a very cheap way to shield exception information from an ASP.NET web service. Mind you, this is available only from ASP.NET 2.0 (and upwards presumably).
So, what is exception shielding for web services? Preventing potentially valuable exception information from leaking to the calling client. It’s a good security practice to shield unhandled exceptions that occurred inside your web service from bubbling up to the ASP.NET HttpHandler for ASMX. Take this web service:
The handler will take over and return a SOAP fault to the client. The <soap:Fault> element will contain (wrapped inside a SoapException) the type and message of the exception that occurred, plus a stacktrace and references to the file location of the source file. It will look like this:
You could jump through hoops to catch all unhandled exceptions that occur inside of your methods and throw your own SoapExceptions (in which case the exception isn’t altered). There is some guidance right here from the Patterns and Practices team.
Or you could set a new ASP.NET 2.0 diagnostics option in your web.config and let the ASP.NET runtime take care of not returning too much exception information.
Setting the suppressReturningExceptions attribute to true (the default is false) will result in no information being included in the returned SoapException. The <soap:Fault> will now contain the following:
I say: recommended for production environments.