Prev: unhandled exception has occurred..
Next: creat DBF in server 2005 with windows vista
From: Scott M. on 11 Dec 2009 13:28

"(PeteCresswell)" <x(a)y.Invalid> wrote in message
news:7i25i5hb8d1i9mm09ruc5co9b30nf2n42i(a)4ax.com...
> 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

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


From: Michael Ober on 12 Dec 2009 10:36

"Mr. Arnold" <Arnold(a)Arnold.com> wrote in message
news:%23kv1r4neKHA.1648(a)TK2MSFTNGP05.phx.gbl...
> (PeteCresswell) wrote:
>> 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?
>
> 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.
>
>
> You may also need Inner Exception message along with the Stack Trace.
>
> http://www.java2s.com/Tutorial/VB/0140__Development/UsepropertiesMessageStackTraceandInnerException.htm

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.

From: Scott M. on 12 Dec 2009 13:17

"Michael Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
news:OfOdnbQQrYURJb7WnZ2dnUVZ_hSdnZ2d(a)earthlink.com...
>
> "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message
> news:%23kv1r4neKHA.1648(a)TK2MSFTNGP05.phx.gbl...
>> (PeteCresswell) wrote:
>>> 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?
>>
>> 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.
>>
>>
>> You may also need Inner Exception message along with the Stack Trace.
>>
>> http://www.java2s.com/Tutorial/VB/0140__Development/UsepropertiesMessageStackTraceandInnerException.htm
>
> 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


From: Michael Ober on 12 Dec 2009 15:08

"Scott M." <s-mar(a)nospam.nospam> wrote in message
news:Ovb7Qc1eKHA.4952(a)TK2MSFTNGP06.phx.gbl...
>
> "Michael Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
> news:OfOdnbQQrYURJb7WnZ2dnUVZ_hSdnZ2d(a)earthlink.com...
>>
>> "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message
>> news:%23kv1r4neKHA.1648(a)TK2MSFTNGP05.phx.gbl...
>>> (PeteCresswell) wrote:
>>>> 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?
>>>
>>> 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.
>>>
>>>
>>> You may also need Inner Exception message along with the Stack Trace.
>>>
>>> http://www.java2s.com/Tutorial/VB/0140__Development/UsepropertiesMessageStackTraceandInnerException.htm
>>
>> 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
>
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.

From: Tom Shelton on 12 Dec 2009 15:19
On 2009-12-12, Michael Ober <obermd> wrote:
>
> "Scott M." <s-mar(a)nospam.nospam> wrote in message
> news:Ovb7Qc1eKHA.4952(a)TK2MSFTNGP06.phx.gbl...
>>
>> "Michael Ober" <obermd.@.alum.mit.edu.nospam> wrote in message
>> news:OfOdnbQQrYURJb7WnZ2dnUVZ_hSdnZ2d(a)earthlink.com...
>>>
>>> "Mr. Arnold" <Arnold(a)Arnold.com> wrote in message
>>> news:%23kv1r4neKHA.1648(a)TK2MSFTNGP05.phx.gbl...
>>>> (PeteCresswell) wrote:
>>>>> 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?
>>>>
>>>> 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.
>>>>
>>>>
>>>> You may also need Inner Exception message along with the Stack Trace.
>>>>
>>>> http://www.java2s.com/Tutorial/VB/0140__Development/UsepropertiesMessageStackTraceandInnerException.htm
>>>
>>> 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
>>
> 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 :)

--
Tom Shelton
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: unhandled exception has occurred..
Next: creat DBF in server 2005 with windows vista