General error handling

[flbos]

I was wondering if it's possible to create a general error handler that handles all errors in a form or maybe even in the application.

I used to program in VBA and I always had to specify an error handler for each procedure I created. My main problem with this always was that I had many small (one or two line) procedures so that it took a tremendous amount of work to add error handlers to all those procedures. I used to use a tool called VZ Tools that allowed me to add a error handler automatically but I still had to do this by one procedure at a time.

So I'd like to know what the best approach is in VB.NET to create an application which handles all errors correctly. Should I still do this on procedure level or are there more advanced solutions available? Maybe with an option to override the general procedure if needed?

Thanks,

Floris

 

[Hokkie]

The error handling is done with Try... Catch... End Try blocks. These blocks can encompass an entire procedure, but also smaller bits of code.

Here's how it looks. This will throw an exception ("raise an error" in VB6 dialect) should aValue2 be zero. This exception is caught by the Catch block and its trace put in a messagebox. Execution will continue with the code after the End Try line.

' This code is untested!

Private Function Division(aValue1 As Integer, aValue2 As Integer) as double

  ' Put some code here, before Try block if you want.

  Try
  
    ' Calculate the Division of aValue1 and aValue2
    Division = aValue1 / aValue2

  Catch ex As Exception
    MsgBox(Ex.ToString)

  End Try

End Function

Alternatively, you can throw exceptions yourself like this:

' This code is untested!

Private Function Division(aValue1 As Integer, aValue2 As Integer) as double

  ' Put some code here, before Try block if you want.

  Try
  
    ' Check for valid values of aValue2
    If aValue2 = 0 Then
      Throw New Exception("Cannot divide by zero.")
    End If

    ' Calculate the Division of aValue1 and aValue2
    Division = aValue1 / aValue2

  Catch ex As Exception
    MsgBox(Ex.Message)

  End Try

End Function

However, you'd have to do this for every procedure just like the old On Error Goto Hell construction. But you won't have to add procedure-identifiable information to any error-object since this is incorporated in the stacktrace of the exception object.

Hope this answers any of the questions you have.

__________________
code is enduring

 

[TipGiver]

Take a look at "My". It provides a general error handler called "Unhandled Exception", if I remember correctly. From the project explorer select the little icon to show all the files, expland form1 and you you see the .vb file .

Hope this helps

 

[flbos]

Thanks for the answers, I understand thing a little bit better now.

However I don't understand why one would use a try catch block for only a part of a procedure. Why not always include the whole procedure?

I can't seem to find "My" and I also don't really get what you are pointing to here. Do I need to look for a file "My.vb" in which I can define a general error handler for uncatched exceptions???

Thanks.

 

[chrissie1]

depends on wich version you are using. My will only work in the 2005 version.

Try to limit the try catch blocks, they slow the app down. Just use them around the blocks you know are going to give problems.


Christiaan Baes
Belgium

I just like this --> [Wiggle] [Wiggle]

 

[jebenson]

Here's a class I use to parse errors and return the procedure and line number of the offending code. Note that the line number code only works in Debug mode - hence the "#If DEBUG" in the usage template.

Public Class ErrParser
Public Shared Function GetProcName(ByVal ErrStackTrace As String) As String
Dim ExeName As String
Dim LastSlashLoc As Integer
Dim NameLoc As Long
Dim TempStr As String
Dim ParenLoc As Integer

ExeName = System.Reflection.Assembly.GetExecutingAssembly.GetName.Name

ExeName = Replace(ExeName, " ", "_")

NameLoc = ErrStackTrace.IndexOf(ExeName)
TempStr = Mid(ErrStackTrace, NameLoc + Len(ExeName) + 2)
ParenLoc = TempStr.IndexOf("(")
GetProcName = Mid(TempStr, 1, ParenLoc)
End Function

Public Shared Function GetErrLineNum(ByVal ErrStackTrace As String) As String
Dim LineLoc As Long

LineLoc = ErrStackTrace.LastIndexOf(":line")
GetErrLineNum = Mid(ErrStackTrace, LineLoc + 6)
End Function
End Class


'Usage Template

'Dim ep As New ErrParser

'Try
' Some Code Here
'Catch ex As Exception
' Dim ErrMsg As String
' ErrMsg = "Error in " & ep.GetProcName(ex.StackTrace)

'#If DEBUG Then
' ErrMsg &= " in Line " & ep.GetErrLineNum(ex.StackTrace)
'#End If

' ErrMsg &= vbCrLf
' ErrMsg = ErrMsg & "Error Message: " & ex.Message
' MsgBox(ErrMsg, MsgBoxStyle.Exclamation Or MsgBoxStyle.OKOnly, "Message Box Title Here")
'End Try

I used to rock and roll every night and party every day. Then it was every other day. Now I'm lucky if I can find 30 minutes a week in which to get funky. - Homer Simpson

 

[BrianB]

You can always add a single handler to the user interface code, button or whatever, then just let called functions pass their errors up. This creates some resource issues, but you can always just do the minimum (clean up db connections or whatever) and just kick the error back up with throw ex. That way you only write one set of ui code to actually report errors. This kind of thing demands good error logging, which leads me to a...

<Shameless Plug>
You could always try an fire and forget bug tracking application, which is coming out in beta this month.

http://www.bugsentry.com

</Shameless Plug>

Brian Begy
Chicago Data Solutions

http://www.chicagodatasolutions.com

BugSentry needs beta testers!

http://www.bugsentry.com