 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / New Users / September 2007Find Name of Function
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? > How can I find the name of the current function being executed. > [quoted text clipped - 18 lines] > Not to sure if this can be done, on binaries not compiled without > debugging symbols. So does anyone care to enlighten me? My bad... void Blah(int? y){ int z; try { z = (int)y; } catch(Exception ex){ throw ex } } 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> > 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. It appears System.Diagnostics.StackTrace and System.Diagnostics.StackFrame classes are your best bet. > > Try using Google search and you will find many suggestions: > [quoted text clipped - 6 lines] > 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... >> > Try using Google search and you will find many suggestions: >> [quoted text clipped - 17 lines] > 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...  Signature-------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer 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. > 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 > How can I find the name of the current function being executed. > [quoted text clipped - 15 lines] > 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). Signature-------------------------------------------------------------------------------- John Saunders | MVP - Windows Server System - Connected System Developer 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. SignatureGregory A. Beamer MVP, MCP: +I, SE, SD, DBA ************************************************* | Think outside the box! ************************************************* > How can I find the name of the current function being executed. > [quoted text clipped - 18 lines] > Not to sure if this can be done, on binaries not compiled without > debugging symbols. So does anyone care to enlighten me? > How can I find the name of the current function being executed. > [quoted text clipped - 18 lines] > Not to sure if this can be done, on binaries not compiled without > debugging symbols. So does anyone care to enlighten me? 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.
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.