Exception Logging Using stack trace

Question

4.00/5 (1 vote)

See more:

I wanted to log the Exception details
Filename , FileLineNo, Method Name (where the exception occured)
This is working using the StackTrace class
But some times i am getting the File Line No and Method Name as null
How shall i track Exception Details all the time when an Exception occur

here is my code

VB

Public Shared Sub LogException(ByVal ex As Exception)

Dim trace As Diagnostics.StackTrace = New Diagnostics.StackTrace(ex, True)
LogInfo(String.Format("Error Message :{0}  => Error In :{1}  => Line Number :{2} => Error Method:{3}",
                                  ex.Message, trace.GetFrame(0).GetFileName(),
                                  trace.GetFrame(0).GetFileLineNumber(),
                                  trace.GetFrame(0).GetMethod().Name))
End Sub

Thanks in advance

Posted 26-Jul-12 8:55am

arun_pk

Updated 26-Jul-12 8:57am

v2

Add a Solution

Comments

fjdiewornncalwe 26-Jul-12 15:07pm

Why are you reinventing the wheel with your own custom logging code. Try using nlog or log4net. They are very efficient and easy to use and the information you want gets where it needs to.

Sergey Alexandrovich Kryukov 26-Jul-12 15:23pm

To be fair, I must say: 1) there is nothing wrong with "re-inventing the wheel"; it all depends on many "what" and "how"; by the way, specialists in real wheels (bikes/auto, mostly) will tell you how many time the wheel were "re-invented", and how efficient it was; 2) the OP's approach is not really "re-inventing the wheel", because the major functionality is in the System.Diagnostics.StackTrace, which is not re-invented. This is exactly what one can do to get the most comprehensive diagnostics possible.

However, your suggestion to use something like nlog and log4net use very useful and should be considered anyway.
--SA

Dave Kreskowiak 26-Jul-12 16:26pm

Yeah, but how much did it cost them to reinvent the wheel yet again??

Sergey Alexandrovich Kryukov 26-Jul-12 23:25pm

No matter; some costs are justified, some are not. OP's approach is not expensive, for certain situations it can be well used.
--SA

Dave Kreskowiak 27-Jul-12 8:03am

The OP's approach is not expensive?? The expense is not CPU cost but in the time he's spending developing and debugging it. How much does he get paid an hour to write this??

Sergey Alexandrovich Kryukov 27-Jul-12 16:29pm

This is exactly what I mean. The stack trace is already implemented, everything else is not expensive. In terms of development work, of course.
--SA

Dave Kreskowiak 27-Jul-12 21:40pm

For you and me maybe, but there are others that don't have enough of a clue to justify the cost. It's all a matter of skill set.

Sergey Alexandrovich Kryukov 27-Jul-12 22:47pm

Agree, that's for sure... I just say that OP's approach should not be denied "by definition". In certain situations, it's quite adequate and feasible. I what situations and for what skill set -- it's a different question.
--SA

Sergey Alexandrovich Kryukov 26-Jul-12 15:30pm

So, I provided the advice in my answer, please see.
--SA

Sergey Alexandrovich Kryukov 26-Jul-12 15:30pm

The question is pretty good, I voted 4.
--SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-07-26T09:30:00

Solution 1

1) The source code line/position information is only available if you compile the code with the debug information. Please see project options for relevant detail.

2) You might miss some very important information; I cannot see if you use Exception.InnerException property. As property is also of the type System.Exception, the returned exception object can also have inner exception, so you need to consider them all, recursively. This feature is often used in some cases.

Also, you should not forget that the exception stacks are separate for each call stack, so you need to catch all exceptions in every thread, at least on the very top stack frame of each thread.

Please also see my comment to the Marcus's comment to the question. Your approach could be useful if you need really comprehensive diagnostics.

—SA

Posted 26-Jul-12 9:30am

Sergey Alexandrovich Kryukov

Comments

arun_pk 26-Jul-12 16:03pm

Thanks for the reply .. I have two way's of catching the exception .
1. Try catch inside some methods and then Log the Exception in a common place
2. Catching application at the very High level
2.1 Using the DispatcherUnhandledException
2.2 Handling the UnhandledExceptionEventArgs

And from you reply . i am sorry i didnt understand how can i compile with the debug information ??
And can you please suggest the best way of getting Details which i mentioned in my question and the InnerException

thanks a lot

Dave Kreskowiak 26-Jul-12 16:39pm

In a Release compile (what you should be shipping to customers) you don't get line number information. You only get that in a Debug build (Build menu -> Configuration Manager -> Active Solution Configurations).

If you're walking the stack trace gettin this file and line number information, you also will not get the data for functions that are residing in libraries and components external to your own code.

Sergey Alexandrovich Kryukov 26-Jul-12 23:25pm

Correct.
--SA

Sergey Alexandrovich Kryukov 26-Jul-12 23:29pm

You need to catch on the top of the stack of each thread. Besides, UI threads has main application loop, where the exceptions can be caught in each cycle. Please see the types named Application (such feature is implemented for WPF and Forms, in different but similar ways).

For InnerException, just look at the documentation on System.Exception -- it's quite clear.

--SA

Sergey Alexandrovich Kryukov 26-Jul-12 23:33pm

...and catching exceptions in some method defeats the purpose of exception handling. However it is done in certain cases:
1) to do some pre-processing and rethrow exception with throw;
2) to do some pre-processing and throw a different exception (turn "general" into "semantic"); the caught exception is often preserved and "packed" in a new exception, usually in the form of InnerException;
3) the propagation of exception is totally blocked; usually this is a very bad idea, but sometime you have to do it to cover some flaws of some bad libraries you cannot afford to patch.
--SA