Wrox Programmer Forums
Go Back   Wrox Programmer Forums > Visual Basic > VB 2005 > Pro Visual Basic 2005
| Search | Today's Posts | Mark Forums Read
Pro Visual Basic 2005 For advanced Visual Basic coders working in version 2005. Beginning-level questions will be redirected to other forums, including Beginning VB 2005.
Welcome to the p2p.wrox.com Forums.

You are currently viewing the Pro Visual Basic 2005 section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old November 30th, 2006, 11:51 AM
Authorized User
 
Join Date: Nov 2006
Location: , , USA.
Posts: 87
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to ef1196
Default Error Reporting With Line Numbers

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
 
Old December 7th, 2006, 07:47 AM
Authorized User
 
Join Date: Aug 2006
Location: Charlotte, NC, USA.
Posts: 21
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to anubisascends
Default

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)
 
Old December 7th, 2006, 04:48 PM
Friend of Wrox
 
Join Date: Nov 2004
Location: Port Orchard, WA, USA.
Posts: 1,621
Thanks: 1
Thanked 3 Times in 3 Posts
Default

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.
 
Old December 8th, 2006, 08:11 AM
Authorized User
 
Join Date: Nov 2006
Location: , , USA.
Posts: 87
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to ef1196
Default

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
 
Old December 8th, 2006, 03:21 PM
Friend of Wrox
 
Join Date: May 2006
Location: San Diego, CA, USA.
Posts: 643
Thanks: 0
Thanked 0 Times in 0 Posts
Default

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
 
Old December 12th, 2006, 08:54 AM
Authorized User
 
Join Date: Nov 2006
Location: , , USA.
Posts: 87
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to ef1196
Default

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
 
Old December 12th, 2006, 11:33 AM
Friend of Wrox
 
Join Date: May 2006
Location: San Diego, CA, USA.
Posts: 643
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Quote:
quote:Originally posted by ef1196
 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.
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
 
Old December 12th, 2006, 01:36 PM
Authorized User
 
Join Date: Nov 2006
Location: , , USA.
Posts: 87
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to ef1196
Default

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
 
Old December 12th, 2006, 02:35 PM
Friend of Wrox
 
Join Date: May 2006
Location: San Diego, CA, USA.
Posts: 643
Thanks: 0
Thanked 0 Times in 0 Posts
Default

Are you using an MSI to deploy your app?

Woody Z
http://www.learntoprogramnow.com
 
Old December 12th, 2006, 02:43 PM
Authorized User
 
Join Date: Nov 2006
Location: , , USA.
Posts: 87
Thanks: 0
Thanked 0 Times in 0 Posts
Send a message via Yahoo to ef1196
Default

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




Similar Threads
Thread Thread Starter Forum Replies Last Post
Reporting Services Error argademahesh SQL Server 2000 1 February 15th, 2007 11:47 AM
I see no line numbers when viewing errors in brows kenn_rosie VB.NET 2002/2003 Basics 2 May 23rd, 2006 09:48 AM
Line Item Numbers needed Bob Hansen Access VBA 1 May 16th, 2006 02:21 PM
error reporting - oddity ab_dev Beginning PHP 1 March 13th, 2006 02:44 PM
[?] Line numbers in VBA Chantale Access VBA 6 November 3rd, 2004 07:17 AM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.