Error Handling

  • Thread starter Thread starter Issac
  • Start date Start date
I

Issac

Hi,

I am working on error handling for my project.
I got the following code from the web which declare that
it can catch all exceptions in my project rather that
using TRY CATCH in everything single sub/function.

\\\
Public currentdomain As AppDomain

currentdomain = AppDomain.CurrentDomain
AddHandler currentdomain.UnhandledException, AddressOf
MyExceptionHandler
AddHandler Application.ThreadException, AddressOf
MyThreadHandler
///

However, I find that some errors occur in Event/Handler
may not be catched with the above code.
(e.g.TextBox_Validated_Handler)
Am I missing something? Or I should use TRY/CATCH in
every single sub/function?

Please help, appreciate.

Regards,
Issac
 
.. . .
I am working on error handling for my project.
Click to expand...

IMO, the two go hand-in-hand; Error (sorry, Exception) Handling
is /not/ something you can sensibly bolt on afterwards.

.. . .
Or I should use TRY/CATCH in every single sub/function?
Click to expand...

(Again, IMO) You should use Try/Catch in every single procedure
*where it is "useful" to do so*. If all you can do it re-Throw the same
Exception, there's not much point in catching it in the first place.
But if you're catching a FileNotFoundException while verifying that
the user really /did/ pick a file in that dialog you're showing them and
them "reminding" them to pick a file that really /does/ exist, then you
need /that/ code as close to the error as possible.

Personally, I dislike generic, catch-all error routines simply because
they can only do something like this:

Sub GlobalEH_FarFarAwayFromTheError( ...
MsgBox( "Oh dear; something went wrong " _
& "- I can tell you /exactly/ where " _
& vbCrLf & oException.ToString() _
& vbCrLf & "(but not ""why"", tee hee) " _
& vbCrLf & "so you can tell the Developer about it " _
& vbCrLf & "but I can't do anything useful to /fix/ it " _
& "so I'm going to stop now. " _
)
End Sub

unless things have changed *radically* in Exception Handling recently,
of course...

HTH,
Phill W.
 
* "Issac said:
I am working on error handling for my project.
I got the following code from the web which declare that
it can catch all exceptions in my project rather that
using TRY CATCH in everything single sub/function.

\\\
Public currentdomain As AppDomain

currentdomain = AppDomain.CurrentDomain
AddHandler currentdomain.UnhandledException, AddressOf
MyExceptionHandler
AddHandler Application.ThreadException, AddressOf
MyThreadHandler
///

However, I find that some errors occur in Event/Handler
may not be catched with the above code.
(e.g.TextBox_Validated_Handler)
Am I missing something? Or I should use TRY/CATCH in
every single sub/function?
Click to expand...

Yes -- you should use 'Try...Catch' there if it makes sense. Have a
look at the documentation for 'Application.TreadException'.
 
Hi Issac,

The try, catch, end try and finally is so easy to use.

If you know how to write an "If", "Else" and "End if" you know how to
write this

Try ' everything goes wrong
every things goes right
Catch ex by exception ' something goes wrong and there are a lot of
exceptions with a lot of operations and there is no problem writing more
Catches in a block (the general exception on the end than).
I have to do something and ex tells me what went wrong
Finally ' what ever happened, this will be executed
By instance a close of an open connection in the try block.
End Try

This you place of course there where could be errors that you can not
suspect when writing a program. Doing this because a user types in a -1 and
you do X/-1 does not need a tryblock, you can check that.

You also can nest this blocks just like if and else and it is very handy.

You use this by instance when you write a file and maybe there is a
diskerror or something. Or with writing to a database (you always should in
my opinion).

I hope this helps a little bit?

Cor
 
Issac,
Am I missing something?
Click to expand...
Where do you have the code?

It needs to be in your Sub Main before you call Application.Run, before you
call anything else really. Your Sub Main needs to be the startup object of
your project.

Assuming Form1 is the Startup Object for the project you need:

Public Class Form1
Inherits System.Windows.Forms.Form

' other stuff omitted

Public Shared Sub Main()
Public currentdomain As AppDomain
currentdomain = AppDomain.CurrentDomain

AddHandler currentdomain.UnhandledException, _
AddressOf MyExceptionHandler
AddHandler Application.ThreadException, _
AddressOf MyThreadHandler

'Application.EnableVisualStyles() ' VS.NET 2003
'Application.DoEvents() ' VS.NET 2003
Application.Run(New Form1)

End Sub
Or I should use TRY/CATCH in
every single sub/function?
Click to expand...
I only include Try Catch in routines that need it, (in routines where I have
something to do other then log the error). I would use the
MyExceptionHandler & MyThreadHandler routines above to log my errors and
"continue" processing.
However, I find that some errors occur in Event/Handler
may not be catched with the above code.
(e.g.TextBox_Validated_Handler)
Click to expand...
The only errors I can think of that would not be caught by the above is
OutOfMemory & StackOverflow errors. However if you get either of those you
really cannot do anything anyway. ;-)

Do you have examples of specific errors that are not caught?

You don't have the "When the exception is thrown - break into the debugger"
& "if the exception is not handled - break into the debugger" options
enabled under "Debug - Exceptions"? as these will cause your code to stop in
the debugger at that point, then when you continue it will go to your
handler...

Hope this helps
Jay
 
Back
Top