| Groups | Blog | Home |
dotnet framework : Find Name of Function
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! | ************************************************* [quoted text, click to view] "Mick Walker" <materialised@privacy.net> wrote in message news:5m1q70Fba1pdU1@mid.individual.net... > 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?
[quoted text, click to view]
"Mick Walker" <materialised@privacy.net> wrote in message news:5m1q70Fba1pdU1@mid.individual.net... > 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. 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). -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
[quoted text, click to view]
"Doug Semler" <dougsemler@gmail.com> wrote in message news:1190903511.591316.39760@k79g2000hse.googlegroups.com... > On Sep 27, 10:11 am, Mick Walker <materiali...@privacy.net> wrote: >> Roger Stewart wrote: >> > Try using Google search and you will find many suggestions: >> >> > <http://www.google.com/search?source=ig&hl=en&q=C%23+get+name+of >> > +current+function> >> >> 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. > > 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... 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... -- -------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer
Try using Google search and you will find many suggestions:
<http://www.google.com/search?source=ig&hl=en&q=C%23+get+name+of +current+function>
It appears System.Diagnostics.StackTrace and
System.Diagnostics.StackFrame classes are your best bet.
[quoted text, click to view]
On Sep 27, 10:11 am, Mick Walker <materiali...@privacy.net> wrote: > Roger Stewart wrote: > > Try using Google search and you will find many suggestions: > > > <http://www.google.com/search?source=ig&hl=en&q=C%23+get+name+of > > +current+function> > > 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. 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...
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
[quoted text, click to view]
Mick Walker wrote: My bad...> 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? void Blah(int? y){ int z; try { z = (int)y; } catch(Exception ex){ throw ex }
[quoted text, click to view]
Roger Stewart wrote: Did that before posting here. I actually found > Try using Google search and you will find many suggestions: > > <http://www.google.com/search?source=ig&hl=en&q=C%23+get+name+of > +current+function> > MethodBase.GetCurrentMethod().Name.ToString() The reason I didn't mention it was because I wanted to find the general
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.
[quoted text, click to view]
Mick Walker wrote: Thanks for all your suggestions.> 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? 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
[quoted text, click to view]
On Sep 27, 6:52 pm, Roger Stewart <rstewart27...@gmail.com> wrote: > 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. 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
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |