StackTrace Question

[jsurpless]

Hi all

I implemented a stacktrace analysis subroutine a while ago and for the most part, it works great... when I process an "unexpected error", I almost always generated something like this

5/13/2009 3:12:35 PM - UNEXPECTED ERROR - MS ACCESS DATABASE TABLE RETRIEVAL FAILED
Module : OleDbCommand
Procedure : GetMSAccess_DatabaseTable
In Line # 10

Exception Type : System.Data.OleDb.OleDbException

however, sometimes my "line number" analysis returns this

In Line # System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling(OleDbHResult hr)
   at System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult(tagDBPARAMS dbParams, Object& executeResult)
   at System.Data.OleDb.OleDbCommand.ExecuteCommandText(Object& executeResult)
   at System.Data.OleDb.OleDbCommand.ExecuteCommand(CommandBehavior behavior, Object& executeResult)
   at System.Data.OleDb.OleDbCommand.ExecuteReaderInternal(CommandBehavior behavior, String method)
   at System.Data.OleDb.OleDbCommand.ExecuteReader(CommandBehavior behavior)
   at System.Data.OleDb.OleDbCommand.System.Data.IDbCommand.ExecuteReader(CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.FillInternal(DataSet dataset, DataTable[] datatables, Int32 startRecord, Int32 maxRecords, String srcTable, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataTable[] dataTables, Int32 startRecord, Int32 maxRecords, IDbCommand command, CommandBehavior behavior)
   at System.Data.Common.DbDataAdapter.Fill(DataTable dataTable)
   at ADG.Class_Database.GetMSAccess_DatabaseTable(String strDatabaseTable)

Here's the code I am using to retrieve the line number

Dim Line_Number As String = Exception_Type.StackTrace.ToString.Substring(InStr(Exception_Type.StackTrace.ToString, ":line ") + 5)

My guess as to the reason for the failure is that sometimes ":line" doesn't appear in this area... why would this be the case and how would you recommend I deal with this?

Many thanks!

-Justin

 

[JohnH]

http://www.vbdotnetforums.com/testi...09-getting-current-file-name-line-number.html

 

[jsurpless]

Hi

Thanks for the reply...

Tried what you suggested and while it's returning a line number, I'm not quite sure as to what line number it is actually returning...

I ask this because the line it returns doesn't seem to apply to the location of the error... it's returning the line number of the command you recommended...

 

[JohnH]

It sounds as you have created a new StackTrace yourself. You'd want to get the one from StackTrace property of the Exception thrown.

 

[jsurpless]

Isn't that what I'm doing above?

Dim Line_Number As String = Exception_Type.StackTrace.ToString.Substring(InStr(Exception_Type.StackTrace.ToString, ":line ") + 5)

 

[JohnH]

I didn't recall Exception.StackTrace property was String type, this is what I meant:

        Catch ex As Exception
            Dim st As New StackTrace(ex, True)
            Dim l As Integer = st.GetFrame(0).GetFileLineNumber

 

[jsurpless]

What is 'ex'?

*Nevermind*... just realized that this is my 'Exception_Type'

Tried this but it doesn't seem to return a non-zero value

Dim CurrentStack As New System.Diagnostics.StackTrace(Exception_Type, True)

Dim Line_Number As String = CurrentStack.GetFrame(0).GetFileLineNumber

 

[JohnH]

"Source information" such as "file name, line number, and column number" is only available for debug builds.

 

[jsurpless]

The code I use above seems to work under *most* instances... what I've done is "built" the application and then used the contents of the debug directory to create an installer...

*Hmmm*... so I can't do this once I've distributed the application? I had originally put this in order to help locate errors that I didn't anticipate... is it possible to better localize the error once distributed?

 

[JohnH]

The exception type and message, method name and call stack is usually sufficient for identifying the problem, where it occured and in what context. In addition you can write custom logging/tracing information to see what is going on in the program flow.

 

[jsurpless]

Can you cite an example of this custom logging subroutine?

Looking at the output I mentioned above, in this case - I can sort of see how to deduce where the error occurred but in a more complex case, I'm not sure...

 

[JohnH]

You should check out all the tools available in System.Diagnostics Namespace. Also see How to: Log Exceptions in Visual Basic and related links.

 

[jsurpless]

Here's the code I'm currently using to log my exceptions...

Dim CurrentStack As New System.Diagnostics.StackTrace(True)
Dim strCalling_Procedure As String = CurrentStack.GetFrame(2).GetMethod.Name

Dim strActiveGlobalName As String = Exception_Type.TargetSite.DeclaringType.Name

Dim Line_Number As String = Exception_Type.StackTrace.ToString.Substring(InStr(Exception_Type.StackTrace.ToString, ":line ") + 5)

Dim strException_Type As String = Exception_Type.GetType.ToString
Dim strException_Type_Message As String = Exception_Type.Message

From what you said above, it seems that in my distributed version - the GetLineNumber does *not* work... there is no way to retrieve the exact line #?

Thanks!

 

[JohnH]

Source code is compiled to IL code (assembly), this is very different from the source, even code structure may change and some debug calls are omitted, whitespace and comments is not relevant for the assembly. At this stage debugging to source code can only be done using a database lookup file, the pdb. When executed the IL is compiled again to native code (machine), this is again very different. Exactly how this maps back to the assembly code I haven't looked into, but with the pdb present the StackTrace is able to lookup the orginal source code line number from something called IL offset. This file is loaded when assembly loads if present, from what I read it does not affect execution performance but it naturally adds to the memory usage. That it is by default not included in deployment packages indicates there is a reason it shouldn't be included, I think this reason is memory, security and that it simply in most cases is not needed. If you look in the advanced compile options you'll see that debug builds include "full info" and no optimization of code, release builds now has "pdb-only" and optimizations, in earlier VS versions no debug info was generated for Release, the reason for this is that you should be able to debug Release configurations also in VS. For deployment the pdb is not included and hidden by default, if you for example see the ClickOnce (Publish) Application Files dialog you can check "show all files" to see the pdb, you can also change the publish status to Include. You should research the implications of doing this. Something I read was that it is possible to setup some kind of Symbols server to hold this information to avoid publishing the pdb. IMO you should not rely on source code line number for deployed Release mode assemblies, it's passed that point in the development cycle.

"Exception_Type" is a bad name for an Exception instance, it indicates that it hold the Type information for the Exception, and not the Exception itself.

 

[jsurpless]

Thanks for the info... unfortunately, I think some of that is a bit over my head - I'm not actually of a programming background - more of a "novice"...

In any case, I had wanted to include the line number to my users to aid in troubleshooting their issues, ones that I had not anticipated...