Find Name of Function

  • Thread starter Thread starter Mick Walker
  • Start date Start date
M

Mick Walker

How can I find the name of the current function being executed.

For example, lets say I have the following function

void Blah(int? y){
int z;
try {
z = y;
}
catch(Exception ex){
throw ex
}
}
Which will throw an exception if y is null(Nullable).
I am writing a class to log any exceptions to a SQL database, a column
indicating the name of the current function where the exception was
generated would be very handy.
So instead of throwing the exception, I would log it, and handle the
exception gracefully.

Not to sure if this can be done, on binaries not compiled without
debugging symbols. So does anyone care to enlighten me?
 
Mick said:
How can I find the name of the current function being executed.

For example, lets say I have the following function

void Blah(int? y){
int z;
try {
z = y;
}
catch(Exception ex){
throw ex
}
}
Which will throw an exception if y is null(Nullable).
I am writing a class to log any exceptions to a SQL database, a column
indicating the name of the current function where the exception was
generated would be very handy.
So instead of throwing the exception, I would log it, and handle the
exception gracefully.

Not to sure if this can be done, on binaries not compiled without
debugging symbols. So does anyone care to enlighten me?
Click to expand...
My bad...

void Blah(int? y){
int z;
try {
z = (int)y;
}
catch(Exception ex){
throw ex
}
}
 
It appears System.Diagnostics.StackTrace and
System.Diagnostics.StackFrame classes are your best bet.
 
Mick Walker said:
How can I find the name of the current function being executed.

For example, lets say I have the following function

void Blah(int? y){
int z;
try {
z = y;
}
catch(Exception ex){
throw ex
}
}
Which will throw an exception if y is null(Nullable).
I am writing a class to log any exceptions to a SQL database, a column
indicating the name of the current function where the exception was
generated would be very handy.
So instead of throwing the exception, I would log it, and handle the
exception gracefully.
Click to expand...

Be careful of how you do this. I see many developers catching exceptions all
over the place, when they should let the exceptions bubble up to a higher
level, to be handled there.

Also, the Exception.Source property usually has good information about where
the exception happened.

I'd suggest that you either log ex.ToString(), or else serialize the
exception object (assuming it is serializable).
 
There is no need to start using Reflection or Diagnostics to find where an
error occurred. The exception has a .Source attribute that can be queried as
the exception rides up the stack.

I would not, as Roger has mentioned, catch exceptions at every level. You
will end up bogging down your application this way, with no real benefit. In
general, unhandled exceptions should be caught as close to the UI as
possible. Other exception handlers should be employed only when there is
some way to actually handle the exception. This is not a firm rule, of
course, but catching simply to throw is not a good strategy.

--
Gregory A. Beamer
MVP, MCP: +I, SE, SD, DBA

*************************************************
| Think outside the box!
|
*************************************************
 
Did that before posting here. I actually found
MethodBase.GetCurrentMethod().Name.ToString()

The reason I didn't mention it was because I wanted to find the general
consensus on how to do it.
Click to expand...

If you are logging exceptions, why not just log the StackTrace member
of the exception as part of your logging method? If there is no pdb
file, you'll be missing the filename and line numbers...

Here's why I would rather have the ENTIRE stack trace rather than just
the current method...imagine that your method is called from 10
different places, but only ONE of those callers is passing in a bad
value. Without knowing the CALLING function, what good would logging
your method name be? Sure, you'd know that Blah failed. But I'd
rather know that "Foo" caused it to fail...
 
Doug Semler said:
If you are logging exceptions, why not just log the StackTrace member
of the exception as part of your logging method? If there is no pdb
file, you'll be missing the filename and line numbers...

Here's why I would rather have the ENTIRE stack trace rather than just
the current method...imagine that your method is called from 10
different places, but only ONE of those callers is passing in a bad
value. Without knowing the CALLING function, what good would logging
your method name be? Sure, you'd know that Blah failed. But I'd
rather know that "Foo" caused it to fail...
Click to expand...

Does anyone feel that logging Exception.ToString() is not enough? I suppose
that one might want to put the .Source into a separate column to enable
grouping...
 
The OP did not mention using obfuscation but I will throw this out
there... You are also opening up another can of worms if you
obfuscate. A stack trace or Exception.Source will be of no value.
 
Mick said:
How can I find the name of the current function being executed.

For example, lets say I have the following function

void Blah(int? y){
int z;
try {
z = y;
}
catch(Exception ex){
throw ex
}
}
Which will throw an exception if y is null(Nullable).
I am writing a class to log any exceptions to a SQL database, a column
indicating the name of the current function where the exception was
generated would be very handy.
So instead of throwing the exception, I would log it, and handle the
exception gracefully.

Not to sure if this can be done, on binaries not compiled without
debugging symbols. So does anyone care to enlighten me?
Click to expand...
Thanks for all your suggestions.

Basically this information will be used in a testing environment. Based
on the type of exception, the appropriate developer will be notified.

It will never be used within a live web application. Its simply a tool
to aid during the testing phase.
 
The OP did not mention using obfuscation but I will throw this out
there... You are also opening up another can of worms if you
obfuscate. A stack trace or Exception.Source will be of no value.
Click to expand...

It should be. When you obfuscate, good tools will produce a mapping
file (which of course you don't distribute) saying which original name
mapped to which output name.

I remember writing a little webapp when we used a Java obfuscator -
you'd paste the stack trace reported by the customer into the tool,
select the build number, and it would give the unobfuscated stack
trace.

Jon
 
Back
Top