Hi KTJ,

Thanks for your feedback!

Yes, I see your concern. I know that you want to control what detailed
information the Exception object contains. We may divide the problem into 2
parts:

1. Just as you have been awared of, the underlying .Net data provider will
do the actual database operation on behalf of ADO.net code. Whenever an
error is generated from SQL Server, the provider will recognize this
situation. It will construct an Exception object and throw out this
exception to the upper layer ADO.net code. The key point is that: the
detailed information that is contained in the Exception object is
constructed when the Exception object is created, and the error message is
passed through the Exception object constructor. That is why we said the
detailed error message is out of control of CLR, but controlled by .Net
data provider.

2. I think your concern is that what we can do on .Net side to reduce the
sensitive information from leaking out, if the .Net data provider really
places sensitive information in the error message. In this scenairo, since
the sensitive information is already placed in the Exception object, what
we can do is parsing the error message to cut out the sensitive
information. I do not think there is a general solution for this approach,
you may just think about all the possible sensitive information
keywords/pattern, then you may use string parsing to trim the sensitive
data/string.

Additionally, regarding #1, if you want to know if .Net data provider
exposes any programming interface for us to control the Exception error
message, my personal experience is no. However, I am not an ADO.net expert,
that's why I said you may contact ADO.net newsgroup for more detailed
confirmation. Thanks for your understanding.

If I have misunderstood your concern, please feel free to tell me. Thanks

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

John .. you should be catching these exceptions in your data layer and
rethrowing your own application exceptions (possibly with the original
exception as an inner exception depending how you are handling it later). As
an example .. while inserting a customer I would have code such as.

try {
   //do insert
}
catch (SqlException Ex) {
   throw new MyDataLayerException("Unable to save customer to the database,
the database returned an error", Ex);
}

Not only does this prevent you from showing undesirable information it also
helps clean up the contract from your data layer .. Your data layer can now
only throw your application exception (as opposed to being able to throw 22
different exceptions).

Also, the information in these exceptions will be quite useful to you when
you need to debug any problems (but should not be shown in a production
application). When you start getting exceptions like these you can do things
such as have them "phone home" ... when they do you can also get the inner
exception to see what has actually happenned.

Someone once told me a great rule of thumb of "never show an exception
directly to the user". I agree with this in principle (an application should
shutdown when it gets an exception, it should not show it to the user except
in some edge conditions like your users happen to be programmers).

Cheers,

Greg

Sorry in last post I meant an "unhandled" exception should never be shown to
a user.