determining line numbers upon error

10 Aug 2006 6:04 AM

JohnR

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...

10 Aug 2006 6:25 AM

Scott M.

> 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.

Show quoteHide quote

>
> Any Ideas? Thanks for any help...
>

10 Aug 2006 1:23 PM

Michel Posseth [MCP]

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]

Show quoteHide quote

"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...
>
>
>