Question on usage guidelines for Exception.TargetSite

[Jim O'Neil [Sybase]]

In designing a new control for general use, I have come across a design
decision involving exceptions...

I know that TargetSite returns the name of the method that threw the
exception; however, will users of the control expect that TargetSite always
reflects the method of the control that they actually called? For example,
consider a method on my class named "publicfoo" that calls some internal
method name "internalbar" (which includes some generalized processing used
by other methods in addition to "publicfoo"). "internalbar" raises an
exception which needs to propagate back to the caller of "publicfoo".

If the user of my control catches the exception, the TargetSite will contain
"internalbar", a method that the end-user knows nothing about. I realize
"publicfoo" will be in the stack trace, but that requires parsing through it
to find the actual method that the control user invoked.

Am I trying to use TargetSite inappropriately here? It seems 'redundant' to
add a MethodName argument to all of my own exceptions and would require
subclassing System exceptions (like InvalidArgumentException) if I want to
provide the MethodName consistently.

I also thought about having "internalbar" return the exception to
"publicfoo" and then "publicfoo" can throw it; however, that seems contrary
to good programming encapsulation and would necessitate logic in all methods
like "publicfoo" to not only throw the exception, but first detect whether
an exception occurred and then throw it. It seems like a potential area for
bugs to creep in, since I (or maintenance programmers) would need to
remember to do this check in any new public method as well.

There seems to be some precedent in ADO.NET for which TargetSite does indeed
report an internal method: when calling OleDbCommand.ExecuteReader, without
an associated connection/transaction, an exception will be thrown in an
internal method called ValidateConnectionAndTransaction and that will be
reported back to the invoking code within the TargetSite property. The
programmer in this case though called ExecuteReader.

In looking at some of the Microsoft Documentation for Class Developers, I
haven't happened across anything that specifies what the 'best-practice' is
in this case. What are your experiences when using other .Net classes?

[Marina]

The issue is that, there can be any number of calls on the stack until the
method that actually threw the error. The method that threw the error is
the one in TargetSite, regardless of whether or not it is a framework
method.

What you can do, is create an instance of the StackTrace class from the
exception object you have. Then, you can examine every frame of the stack
trace, look at the function name, assembly name, etc, and figure out which
one is the one you want to display to the user.

"Jim O'Neil [Sybase]" <jo****@sybase.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

In designing a new control for general use, I have come across a design
decision involving exceptions...

I know that TargetSite returns the name of the method that threw the
exception; however, will users of the control expect that TargetSite always reflects the method of the control that they actually called? For example, consider a method on my class named "publicfoo" that calls some internal
method name "internalbar" (which includes some generalized processing used
by other methods in addition to "publicfoo"). "internalbar" raises an
exception which needs to propagate back to the caller of "publicfoo".

If the user of my control catches the exception, the TargetSite will contain "internalbar", a method that the end-user knows nothing about. I realize
"publicfoo" will be in the stack trace, but that requires parsing through it to find the actual method that the control user invoked.

Am I trying to use TargetSite inappropriately here? It seems 'redundant' to add a MethodName argument to all of my own exceptions and would require
subclassing System exceptions (like InvalidArgumentException) if I want to
provide the MethodName consistently.

I also thought about having "internalbar" return the exception to
"publicfoo" and then "publicfoo" can throw it; however, that seems contrary to good programming encapsulation and would necessitate logic in all methods like "publicfoo" to not only throw the exception, but first detect whether
an exception occurred and then throw it. It seems like a potential area for bugs to creep in, since I (or maintenance programmers) would need to
remember to do this check in any new public method as well.

There seems to be some precedent in ADO.NET for which TargetSite does indeed report an internal method: when calling OleDbCommand.ExecuteReader, without an associated connection/transaction, an exception will be thrown in an
internal method called ValidateConnectionAndTransaction and that will be
reported back to the invoking code within the TargetSite property. The
programmer in this case though called ExecuteReader.

In looking at some of the Microsoft Documentation for Class Developers, I
haven't happened across anything that specifies what the 'best-practice' is in this case. What are your experiences when using other .Net classes?