At work I have inherited an extremely large VB2k5 application and at times it generates errors that are difficult to track.

Due to the nature of the application reproducing errors after they happen is often not possible.

Within my Error Trap routine I am able to get the calling procedure/function by examining Ex.TargetSite.Name (Where EX is an EXCEPTION). In addition I obviously get the error message itself, but what I would like is the line number of the offending procedure/function.

I have examined Environment.StackTrace.ToString as a method of retrieving a line number, but it seems to point to the "catch" portion of the "try/catch" statement rather than where the error actually occurred.

Some websites I have visited suggest (but don't document well) that including the .pdb file with your application will allow your error trap routine to display line numbers.

All thoughts and possible solutions are appreciated in advance!






Best Regards,
Earl Francis

__________________


Best Regards,
Earl

This might help a little, this will give you the sub that caused the error, so it can narrow the search down a little:

http://forums.microsoft.com/MSDN/Sho...81597&SiteID=1

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.
Albert Einstein
US (German-born) physicist (1879 - 1955)

Create a variable within the routine, change its value at selected points, then, in the catch block, report the value of that variable. It could be a string, so that the value you change it to at the selected points can be concatenations of loop values and descriptions of the location, or it could be a simple integer.

If you do this with a global variable, you could carry information from function call to function call.

Thanks Andrew and Brian.

Brian, yours is an interesting approach, but it would have been nice if Redmond, WA would have left this functionality in the .NET versions (or if it is still here to have made it easier to find within the EXCEPTION class).

VB6's Err.LineNumber was a solid method of debugging an app. Oh well...



Best Regards,
Earl Francis

You can actually get the line of code that allowed the original exception to be thrown.
This is done using the inner exception.

In the code with the initial try/catch, declare an exception and place the exception caught into its inner exception member (and add whatever info you need to the new exception itself). You then throw that exception. When you display the exception somewhere in your UI code, check for the existance of an inner exception and you will find the line number in there.

Additionally you can follow a similar structure all the way up the call stack if there is some further value to adding additional info as you go. Just remember that exception handling in the .NET world should be used only for true exception handling, where in VB6 we often used error handling as part of the logic sometimes. In .NET there can be a serious performance hit as there is a great deal of overhead.

Another note: Remember that you can create your own exception classes that inherit from the base Exception class, and have a very full featured exception handling system.

Have fun.

Woody Z
http://www.learntoprogramnow.com

Are you sure about this Woody?

The line numbers will definitely appear within the Exception class (Ex.ToString - where Ex is the EXCEPTION) if you are in the development environment, but once the application is compiled and published I have not found this to be the case.

In addition, an Inner Exception is not always produced by the Exception class and can lead to a NULL Reference error if not properly handled within the error routine.

Disclaimer: I'm not proclaiming my point of view to be 100% correct. If I knew everything I wouldn't bother with forums.





Best Regards,
Earl Francis

First of all, I'm not proclaiming my point of view to be 100% correct, but only that I always THINK I'm 100% correct.

Okay - YES about the line numbers. You must set the "Generate Debugging Information" property to true for each project that you want line numbering for, and then deploy the pdb files with the exe and dll files. This isn't something you want to do all the time, perhaps, but I see no serious reason not to in an internal corporate application, at least until the app is highly stable. There might be some performance hit, but if the project is designed properly this shouldn't be an issue as it will only appear in EXCEPTIONAL cases - that is, when an exception is thrown and needs to be handled so this should be very rare in the normal flow.

And regarding the Inner Exception. The inner exeception is always there if I put it there. Regardless, the code that "unravels" the excpetion has to be written in such a way to deal with all possibilities - so that shouldn't ever be a problem.

We did have a case where in a remoting situation we weren't getting the underlying inner exception but from what I recall we worked that out. So, I am not sure that in our code we have any situation where we can't get at an inner exception where we ourselves have initially generated one. The main focus of my work is a project that, like yours, is large as well. With about 2 million lines of code in the "core" modules, plus numerous optional modules, and code running on various tiers, if we weren't able to easily get at the location of an exception it would be a serious issue.



Woody Z
http://www.learntoprogramnow.com

My issues related to the location of the .PDB when the application is published.

After all the dialogue (which is appreciated) here is what I have FINALLY discovered:

I knew that the .PDB file needed to be included in the project in order to access line number info in the EXCEPTION, but it seems that I have to compile and then manually copy the .PDB to the root application folder (along side forms, etc.) and then set THAT version to "INCLUDE IN PROJECT" ("Copy To Output Directory" property = "Copy Always") in order for the published application to be able to properly access the .PDB debug info.

You're previous suggestions were (100%) correct, it was just a matter of my app not being able to find the debug info.

If you've got a better solution for publishing the .PDB (as this is obviously a work around), bring it on. Otherwise this one is considered closed.

Thanks Woody!




Best Regards,
Earl Francis

Are you using an MSI to deploy your app?

Woody Z
http://www.learntoprogramnow.com

I am using the Publish option off of "My Project". Our applications (at least for now) do not require a deployment project.



Best Regards,
Earl Francis