Line Numbering?

[(PeteCresswell)]

Are line numbers in VB.NET coding totally passe'?

I've used them for years in VBA coding. My error trapping
writes the error and line number to a .txt file and it's been
very helpful in speeding up the process of finding/fixing errors.

Or is there some functional equivalent in the .NET scheme of
things?

 

[Scott M.]

Are line numbers in VB.NET coding totally passe'?

I've used them for years in VBA coding. My error trapping
writes the error and line number to a .txt file and it's been
very helpful in speeding up the process of finding/fixing errors.

Or is there some functional equivalent in the .NET scheme of
things?

VBA is not compiled code like .NET is. When you get a runtime error in a
VBA app., you can go straight to that line and see what's going on. When
you get an exception in a .NET applicaiton at runtime, you're getting an
exception in the compiled Intermediate Language code that is being processed
by the CLR, not from the source code per se.

In .NET, when you realize that you have runtime exceptions, you first need
to know what assembly they are eminating from and then the stacktrace of the
exception will give you guidance as to what part of the code was being
executed when the exception occured.

In general, you can use Try...Catch blocks around code that *may* break at
runtime and you can then log your exceptions by looking at the exception's:
name, type, innerException, and stacktrace.

-Scott

 

[(PeteCresswell)]

Per Mr. Arnold:

You do a Stack Trace in the error trapping code in .NET for VB or C#
code, it will give the class name and the line number in the class where
the error occurred when using try/catch is being used.

I think it's starting to soak in.

Is it common practice to have a single error handling routine
that is called by "Catch" - and which writes relevant info to a
..txt file?

 

[(PeteCresswell)]

Per (PeteCresswell):

Is it common practice to have a single error handling routine...

I retract that question. Seems tb a *lot* of stuff out there on
error handling... e.g.
http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx#Don'tthrownewException()7

 

[Scott M.]

Per Mr. Arnold:

I think it's starting to soak in.

Is it common practice to have a single error handling routine
that is called by "Catch" - and which writes relevant info to a
.txt file?

You surround any code that *might* fail at runtime with a Try...Catch block.
Because some code can fail for different reasons, you may choose to have
several Catch blocks stemming from just one Try, as in:

Try
'Place code that *may* fail at runtime here

Catch ex As OverflowException
'Deal with Overflow exceptions that get caught here

Catch ex As InvalidCastException
'Deal with casting exceptions that get caught here

Catch ex As Exception
'Deal with any exception that hasn't already been caught here

End Try

Remember that Try...Catch is not a substitute for writing good code. When I
say you try code that *might* fail, I mean *might* fail, through no fault of
your code. Things like the network being down or a server being offline
could certainy cause your code to fail even though you've coded your end
correctly. Attempting to divide some user input by 3 without checking the
user input to see if it is a non-zero number first is NOT what Try...Catch
is for.

What you actually do in the Catch blocks is up to you. Many people write
information about the exception into the Event log, rather than a text file,
but it's up to you.

-Scott

 

[Scott M.]

To get the line number, you need to do a Debug release. The Release
configuration doesn't appear to give line numbers. It makes the exe a
little bigger but doesn't appear to impact performance in most cases.

Mike.

Actually, providing a Debug version as your production version can
absolutely impact performance. Generally, the larger the assembly, the
larger the impact.

-Scott

 

[Tom Shelton]

It depends - if your application spends most of its time waiting for io of
any sort, then the overhead is miniscule. If you application spends a lot
of time CPU bound, then it is definitely a factor.

Is there anyway to get the line numbers from a crash in the "Release" build
versions?

Mike.

By default, even in release mode, vs generally generates pdb files for the
executable. These contain symbol and line information - so as long as you
distribute these with your exe, then I believe the information will be
included in the stack trace...

You can see this if you compile for release mode, and then run the exe in the
bin directory...

private void Window_Loaded ( object sender, RoutedEventArgs e )
{
try
{
throw new Exception ( "butt monkeys!!! ATTACK!" );
}
catch ( Exception ex)
{
MessageBox.Show ( ex.StackTrace );
}
}

With the pdb files, the message box shows:

at FANote.MainWindow.Window_Loaded(Object sender, RoutedEventArgs e) in
C:\Users\Tom\Documents\Visual Studio 2008\Projects\FANote\FANote\MainWindow.xaml.cs:line 31

If I then delete the pdb files and run the code i get:
at FANote.MainWindow.Window_Loaded(Object sender, RoutedEventArgs e)

Of course you may not want to ship the pdb files - but if you generate them
and then keep them, you might be able to supply them if the program begins
crashing

 

[Gregory A. Beamer]

Are line numbers in VB.NET coding totally passe'?

I've used them for years in VBA coding. My error trapping
writes the error and line number to a .txt file and it's been
very helpful in speeding up the process of finding/fixing errors.

Or is there some functional equivalent in the .NET scheme of
things?

The line numbers are there in .NET, but you don't type them in. When you
get a stack trace, you will get a line number. Turn on line numbers in
Visual Studio and viola ... they correspond. So there is no reason to
have typed in line numbers any more.

As far as finding/fixing errors go in .NET, there are two suggestions;

1. Learn how to use the debug tools.
2. Learn enough about the framework to be able to decode what the stack
tells you about an error.

On point #2: Often times, people post a stack trace here asking what is
going on. If the poster had taken a bit of time reading the stack, the
classes would give away what many of hte errors were. Understanding the
flow of the stack would give away others. And being able to find the
erroring class in the help files would solve another heap of issues. It
is not a 100% thing, but it is well over the 80% mark.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************

 

[Gregory A. Beamer]

Is it common practice to have a single error handling routine
that is called by "Catch" - and which writes relevant info to a
.txt file?

It depends on where the try ... catch is. if you bubble everything up to
the UI, then sending everything to a single logger may make sense, as
your primary purpose of this type of exception handler is to make sure
the user does not see ugly error messages.

If you are capturing exceptions lower down in the layers, you may call a
single logger, but it is unlikely you would have a single "On Error Goto
Label" type of catch mechanism (ala VB6 or VBA).

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************