Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Using Err.Raise question

Status
Not open for further replies.

remeng

Technical User
Jul 27, 2006
520
US
Hi

I was reading about Using Err.Raise and I had a question or few that I was holing someone could answer. Here is the article I am referencing: Link

If I were to add Err.Raise to the code, when an error occurs in the section of code, it should go to Pub Cost ERROR_INVALID_DATA. If there is an ON ERROR GOTO eh, that should override the Err.Raise?

Which takes priority over the other? What are the conditions that this occurs? If Err.Raise is before ON ERROR GOTO eh, does Err.Raise default or will ON ERROR GOTO eh override the Err.Raise?
 
Code:
     If Len(Sheet1.Range("A1")) <> 5 Then
        Err.Raise ERROR_INVALID_DATA, "ReadWorksheet" _
            , "The value in the cell A1 must have exactly 5 characters."
End If


Code:
 Public Const ERROR_INVALID_DATA As Long = vbObjectError + 513

Sub ReadWorksheet()

    On Error Goto eh
    
    If Len(Sheet1.Range("A1")) <> 5 Then
        Err.Raise ERROR_INVALID_DATA, "ReadWorksheet" _
            , "The value in the cell A1 must have exactly 5 characters."
    End If
    
    ' continue on if cell has valid data
    Dim id As String
    id = Sheet1.Range("A1")
    

Done:
    Exit Sub
eh:
    ' Err.Raise will send code to here
    MsgBox "Error found: " & Err.Description
End Sub

Thanks,

Mike
 
Hi,

Err.Raise does not cause your code to Goto eh. It is the On Error Goto eh along with whatever line of coder caused the error.

Good error handling takes a lot of careful analysis and thought.

Confession: I did very little error handling in my VBA, because almost all was for me as an aid to accomplish my job. When I did encounter an error, (usually data or situational) I fixed the data or modified the situation and went on.

If you are coding for a release to a customer base, you better have tested to the break point, every feature of your application and made it idiot-proof. On those few occasions that I did release to a customer base, I probably spent 3 to 4 times more effort, than just coding a solution, to attempt to make it idiot-proof.

Skip,
[sub]
[glasses]Just traded in my OLD subtlety...
for a NUance![tongue][/sub]
"The most incomprehensible thing about the universe is that it is comprehensible" A. Einstein

You Matter...
unless you multiply yourself by the speed of light squared, then...
You Energy!
 
Consider this trivial example:

Code:
Public Sub Example1()
Dim A As Integer
Dim B As Integer

A = 1
B = 0

Debug.Print A / B

End Sub

Divide by zero error and your program stops ungracefully.

Add a simple error handler:
Code:
Public Sub Example2()
Dim A As Integer
Dim B As Integer

On Error GoTo eh

A = 1
B = 0

Debug.Print A / B

Exit Sub

eh:
MsgBox "Oops! " & Err.Number & " " & Err.Description

' do something else useful here

End Sub

The same division by zero error happens, but this time the program exits gracefully under your control.
In my trivial example2, the control is just a message box, but by replacing my comment 'do something useful here with something useful allows the program to continue, the way you want it to in this case.

As a side effect, we've also learned that the Err.Number for division by zero is 11.

You can see a list of the predefined by VBA errors here:
Notice that there is no predefined error for Len(Sheet1.Range("A1")) <> 5

Step things up a bit more and correct some syntax errors in the example from your original link and we get something very similar to the original example.

Code:
Public Sub Example3()
Dim A As Integer
Dim B As Integer


On Error GoTo eh

A = 1
B = 0

If B = 0 Then
    Err.Raise Number:=vbObjectError + 1051, Description:="Why did you set B = 0?  You know that will break your code!"
End If

Debug.Print A / B

Exit Sub

eh:
MsgBox "Oops! " & Err.Number - vbObjectError & " " & Err.Description

' do something else useful here

End Sub


We have defined our very own error. It has Err.Number = 1051 and Err.Description = "Why did you set B = 0? You know that will break your code!"
In Example 3 I've replaced the default division by zero error with my own.

But Err.Raise gives you the ability to define any error condition that you want. In Example3 the condition is If B = 0.

Your fundamental confusion is this:
remeng said:
when an error occurs in the section of code, it should go to Pub Cost ERROR_INVALID_DATA. If there is an ON ERROR GOTO eh, that should override the Err.Raise?

Err.Raise is not an alternative to On Error GoTo.

Err.Raise gives you the ability to create an error wherever you might need one, for whatever condition you define for On Error GoTo to catch and work with.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top