469,568 Members | 1,378 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,568 developers. It's quick & easy.

determining line numbers upon error

Hi,
I'm looking for some advice and guidance. I have a program in vb.net and I
know that when it's run and the pdb file is available that the exception
will contain the line number of the error. Obviously when trying to track
down an error this is extremely valuable. I've also heard people say that
when you distribute your app, you should compile it without debug and
without the pdb file. In this case the exception has no error numbers.

My question is 2 part. First why shouldn't you distribute a debug version
with a pdb file. If an error occurs while a customer is running your
program the exact line number can be written to a log file and it greatly
speeds up the time necessary to find and fix the bug.

Second, assuming there are good reasons not to distribute a debug version,
does anybody know of a technique (other than updating a public variable with
an incrementing number every other line of code) that would help to narrow
down where an error occurs. I know about the unsupported ERL function but
I believe that works only with an ON Error stmt, and I use structured Try
Catch blocks throughout the program.

Any Ideas? Thanks for any help...
Aug 10 '06 #1
2 1624
My question is 2 part. First why shouldn't you distribute a debug version
with a pdb file. If an error occurs while a customer is running your
program the exact line number can be written to a log file and it greatly
speeds up the time necessary to find and fix the bug.
Because the customer shouldn't be debugging and fixing your code. Sending
out an assembly compiled with debug mode turned on generally results in
slower executing code as well.
Second, assuming there are good reasons not to distribute a debug version,
does anybody know of a technique (other than updating a public variable
with an incrementing number every other line of code) that would help to
narrow down where an error occurs. I know about the unsupported ERL
function but I believe that works only with an ON Error stmt, and I use
structured Try Catch blocks throughout the program.
If you are using Try...Catch statements, create log entries about any
exceptions you encounter. The line number is not paramount.
>
Any Ideas? Thanks for any help...

Aug 10 '06 #2

Hi John
why shouldn`t you deploy a debug version ?? well the answer is simple
performance and you make it easier for someone to reverse engineer your
application if you do so .

Ideas ??

Make sure your application is tested sufficiently , if you encounter a
customer with a problem , just ask them the parameters that let the error
occur and test it in your dev environment .
regards

Michel Posseth [MCP]

"JohnR" wrote:
Hi,
I'm looking for some advice and guidance. I have a program in vb.net and I
know that when it's run and the pdb file is available that the exception
will contain the line number of the error. Obviously when trying to track
down an error this is extremely valuable. I've also heard people say that
when you distribute your app, you should compile it without debug and
without the pdb file. In this case the exception has no error numbers.

My question is 2 part. First why shouldn't you distribute a debug version
with a pdb file. If an error occurs while a customer is running your
program the exact line number can be written to a log file and it greatly
speeds up the time necessary to find and fix the bug.

Second, assuming there are good reasons not to distribute a debug version,
does anybody know of a technique (other than updating a public variable with
an incrementing number every other line of code) that would help to narrow
down where an error occurs. I know about the unsupported ERL function but
I believe that works only with an ON Error stmt, and I use structured Try
Catch blocks throughout the program.

Any Ideas? Thanks for any help...
Aug 10 '06 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by drew | last post: by
6 posts views Thread by Kenneth Courville | last post: by
19 posts views Thread by Allagappan | last post: by
5 posts views Thread by Bob Day | last post: by
18 posts views Thread by Ed Bitzer | last post: by
reply views Thread by suresh191 | last post: by
4 posts views Thread by guiromero | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.