6
\$\begingroup\$

I am using a way of making error messages, and it works fine. It is just starting to get a little annoying as my project gets larger.

I was wondering if there was a way to do with with out having to rename every part of the error, and make a code so it would pick up the function it occurred in.

Private Sub tsbEditNeighbour_Click(sender As Object, e As EventArgs) Handles tsbEditNeighbour.Click
    ' Error Checking

    On Error GoTo Err_tsbEditNeighbour_Click

    Dim CurrentRow As DataRowView = TryCast(PropertyNeighboursLoadRecordsBindingSource.Current, DataRowView)

    ' Load Warranty
    Dim uNeighbours As New frmNeighbours
    With uNeighbours
        .PropertyID = Val(lblPropertyIDValue.Text)
        .NeighbourID = Val(CurrentRow("NeighbourID"))
        .LoadNeighbours()
        .ShowDialog()
        Me.Show()
    End With


Err_tsbEditNeighbour_Click:
    If Err.Number <> 0 Then
        sErrDescription = Err.Description
        WriteAuditLogRecord(Me.Name, "tsbEditNeighbour_Click", "Error", sErrDescription)
        MsgBox("System Error occurred" & Chr(13) & "tsbEditNeighbour_Click" & Chr(13) & sErrDescription, MsgBoxStyle.Exclamation + MsgBoxStyle.OkOnly, "AztecCRM - Error Reporting")
    End If
End Sub
\$\endgroup\$
  • \$\begingroup\$ Hey Richard, I updated the tags on your question. VB6 doesn't event handle that way to the best of my knowledge, but vb.net does. Please let me know if I made a mistake. \$\endgroup\$ – RubberDuck Feb 4 '15 at 16:17
11
\$\begingroup\$

There's probably much more to say about this code, but there's one point that deserves immediate and serious attention: You're handling errors the way and did it... but this code can only be :

Handles tsbEditNeighbour.Click

In the .NET world, you throw away all this On Error GoTo Madness, and work with Exceptions instead.

Exceptions are a much more robust way of handling errors, and give you much more information than just an error number and description (including the whole stack trace, and the exact code file and line number that threw the exception): see System.Exception on MSDN.

The basic idea is that you try some code, and catch to handle any exceptions thrown:

Try
    'some code
Catch ex As Exception
    'error-handling
End Try

See Try-Catch-Finally statements on MSDN for the full syntax.


I'll get back to this post later, to review other points.

\$\endgroup\$
8
\$\begingroup\$

So, you have a couple of issues here. First, your question...

What I've done in VB6 (which your question was originally tagged as) is create a module that is responsible for reporting errors and logging them. I would imagine seeing your error handler look something like this.

If Err.Number <> 0 Then
    ReportError(Me.Name, "tsbEditNeighbor_Click", Err)
End If

Where the rest of your logic resides in the ReportError sub.

But that's . I don't know what the best practice is for and that's what you're using. Which means that the kind of error handling that you're using is antiquated and only exists for backward compatibility. Any newly developed code should take advantage of the Try...Catch blocks. You can read about them on msdn, but here's some psuedo code of what the pattern should look like.

Private Sub tsbEditNeighbour_Click(sender As Object, e As EventArgs) Handles tsbEditNeighbour.Click
    Try

    Dim CurrentRow As DataRowView = TryCast(PropertyNeighboursLoadRecordsBindingSource.Current, DataRowView)

    ' Load Warranty
    Dim uNeighbours As New frmNeighbours
    With uNeighbours
        .PropertyID = Val(lblPropertyIDValue.Text)
        .NeighbourID = Val(CurrentRow("NeighbourID"))
        .LoadNeighbours()
        .ShowDialog()
        Me.Show()
    End With

    Catch ex As Exception 'only don't catch all exceptions, just catch the ones you plan to handle
        ' report the exception here
    Finally
        ' maybe there's some clean up to be done
    End Try
End Sub   
\$\endgroup\$
  • \$\begingroup\$ ahhh yes this makes this alot handier Exactly what I am looking for cheers @RubberDuck \$\endgroup\$ – Richard Glass Feb 4 '15 at 17:01
  • \$\begingroup\$ This way is alot better but its not just 100% what i was meant to ask for I didnt work my question correctly, I was also wondering if there was a way for the error to pick up where the error occurs for example in this case tsbEditNeighbour_Click but with out having to manually type this every time? \$\endgroup\$ – Richard Glass Feb 5 '15 at 10:35
  • 1
    \$\begingroup\$ Take a look at targetsite and stacktrace. \$\endgroup\$ – RubberDuck Feb 5 '15 at 10:40
  • 1
    \$\begingroup\$ @RichardGlass when I catch an exception, all I care for it the stack trace: exceptions bubble up the call stack, showing every caller between the exception being thrown and it being handled; logging just the method name that catches the exception doesn't tell you where is was thrown... \$\endgroup\$ – Mathieu Guindon Feb 5 '15 at 12:50
  • \$\begingroup\$ Yes I can see this when using it, Tells you all you need to know thanks very Much \$\endgroup\$ – Richard Glass Feb 5 '15 at 15:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.