CODEWITHSUNDEEP
vb6
Dexter Naru
Dexter Naru

Reputation: 233

err.number is 0 but fails to compile (vb6)

I have the following code

Private Sub Command1_Click()
    Dim vValidar As Integer

    If (MsgBox("Desea Generar el Arqueo?", vbYesNo + vbQuestion) = vbNo) Then Exit Sub

    frmEspere.Show
    If err.Number Then MsgBox ("Error code = " & err.Number & " Description: " & err.Description)
    On Error GoTo err
    vValidar = 0

It stops execution just after I accept the msgbox (it goes to err:). When I check err.number it's value is 0. err.descritpion doesn't return anything. Is there a way that I can see why if fails?

Upvotes: 1

Views: 543

Answers (1)

Mark Bertenshaw
Mark Bertenshaw

Reputation: 5689

You have obviously not compiled this code properly, and it is interpreting it on the fly. When using VB6, always fully compile your code (CTL-F5). As a result, VB6 doesn't realise that the err label does not exist until you actually try to GoTo it. None of this code makes sense. You are not providing any error handler, before calling frmEspere.Show, but you are reading back the error number right after that method is called. If frmEspere.Show raised an error, your program would crash immediately, so it would never get to the next line. I suggest you read up the topic of error handling in Visual Basic. But to give you a start, there are two styles of using error handling that you could make your code work.

First of all, there is the "jump to error handler" style:

Private Sub Command1_Click()
    
    Dim vValidar As Integer

    On Error GoTo ErrorHandler
    
    If (MsgBox("Desea Generar el Arqueo?", vbYesNo Or vbQuestion) = vbNo) Then Exit Sub
    
    frmEspere.Show
    
Exit Sub

ErrorHandler:
    MsgBox "Error code = " & err.Number & " Description: " & err.Description
End Sub

And there is the "inline error handler" style:

Private Sub Command1_Click()
    
    Dim vValidar As Integer
    
    On Error Resume Next
    
    If (MsgBox("Desea Generar el Arqueo?", vbYesNo Or vbQuestion) = vbNo) Then Exit Sub
    
    frmEspere.Show
    
    If Err.Number <> 0 Then MsgBox "Error code = " & Err.Number & " Description: " & err.Description
    
End Sub

Both styles treats all errors as if they were hidden return values from the statement or method you called (which when calling into ActiveX components is exactly what is happening). After the error has occurred, the statement your called is preemptively terminated, and the Err object is populated with the Number, Description and Source properties.

My personal preference is the former style. Essentially, you are writing an exception handler - errors shouldn't normally occur as part of the normal functioning of your application. When you jump to the error handler, you can use the Number property to decide what to do next. If you use this style, you have three options:

  • Exit the method (potentially returning state via ByRef parameters or return value).
  • Resume to another label in the same method.
  • Call Err.Raise to reraise the current error, or raise a different error.

When using this style, you should really ensure that the main code calls Exit Sub before the error handler label.

With the latter style, you don't jump to an error handler, just the statement after the one which raised an error. You can ignore the error if you want to (I wouldn't), but like the former style, you can:

  • Exit the method (potentially returning state via Ref parameters or return value).
  • Continue on to the next line.
  • Call Err.Raise to reraise the current error, or raise a different error.

I've taken out vValidar = 0 because it is pointless. I changed vbYesNo + vbQuestion to vbYesNo Or vbQuestion because that parameter represents a series of flags which should be OR'd together. Every example you may have seen, including Microsoft's own is misleading.

Upvotes: 3

Related Questions