|
-
Jun 4th, 2000, 06:46 PM
#1
Thread Starter
Junior Member
I`m hoping someone can explain how On Error is properly used. From what I can understand, you place the On Error before a piece of code that may generate an error. When the error is generated, the program jumps to the error handling code and deals with it. The problem I am having is how do you define the scope of the error.
For example, If I place an On Error before the code...
On Error DealWith:
Evil code that generates an error when accessing a database because of NULL
DealWith:
Code to display an error message, etc..
If no error is generated then will the program not jump to the DealWith the next time an error is generated. Also, how do you stop the code under DealWith from being executed. I really don`t understand. Perhaps I have got this wrong but should it not be more like a function with a clear beginning and end so that it is only called when an error is created. PLEASE HELP !!
-
Jun 4th, 2000, 07:17 PM
#2
transcendental analytic
You should place the errorhandling in the end of your procedure. And before the errorhandling put and exit sub/exit function/exit property, then the errorhandling will only execute when error occurs.
Resume - will return back to code
Err - is the error number
Erl - is the line were the error occured
Error Err - Shows the error occurred.
Use  
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jun 4th, 2000, 07:26 PM
#3
Thread Starter
Junior Member
Thanks, never thought of that
-
Jun 4th, 2000, 08:36 PM
#4
Your Sub or Function with error-handling code should be structured something like the following:
Code:
Private Sub MySub()
On Error GoTo SomethingBadHappened
' regular code here
EXIT SUB
SomethingBadHappened:
Msgbox "The following error occurred: Error # " _
Err.Number & " - " Err.Description
END SUB
"It's cold gin time again ..."
Check out my website here.
-
Jun 4th, 2000, 09:09 PM
#5
Lively Member
You can also use Case if you know a couple of error that may occure.
Example from the code above. In the regular code you may open a file for input.
Code:
Private Sub MySub()
On Error GoTo SomethingBadHappened
' regular code here
EXIT SUB
SomethingBadHappened:
Select Case Err.Number
Case 53: MsgBox "ops, no file with that name!"
Resume Next
Case Else: Msgbox "The following error occurred: Error # " & Err.Number & " - " Err.Description
End Select
END SUB
-
Jun 5th, 2000, 04:49 AM
#6
To ignore the Error, use...
Code:
On Error Resume Next
-
Jun 5th, 2000, 05:13 AM
#7
Gee a bug there Guys,
If you use the following code
MsgBox Err.Number
you are going to get a runtime error
Use
MsgBox Str(Err) ' the "Number" append is not needed as is the default property.
-
Jun 5th, 2000, 05:29 AM
#8
transcendental analytic
hmmm, get errors when you are errorhandling, that's too buggy, handle those error too. Heres my opinion:
Try to avoid errorhandling as much as possible and if they are still nessesary, put them in separate procedures that you can call from your code.
Use  
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jun 5th, 2000, 05:33 AM
#9
Kedaman..yeap it suxs
The error is in the MsgBox. Want handle numerics and that is the datatype of the Err.Number. All is not lost..apparently in vb7 we get true error handling routines which bypass this "On Error" rubbish.
-
Jun 5th, 2000, 05:45 AM
#10
Jethro, I beg to differ. "Msgbox Err.Number" will NOT produce a run-time error. VB will perform "evil type conversion" and convert the number to a string (equivalent to doing the CStr yourself).
"It's cold gin time again ..."
Check out my website here.
-
Jun 5th, 2000, 05:52 AM
#11
BruceG ok version difference maybe
We use vb5 sp3 and it does produce a runtime error. Maybe this is not the case in vb6. I personnally know it does coz my boss (the creature from the black lagoon, Kim if you are reading this am only joking), dragged me across the coals for introducing this bug into a release version of our software.
On Error was put in to trap database connection errors. Got an error executed the MsgBox and boom runtime error. Replaced the Err with Str(Err) problem resolved.
Hmmm...should have mentioned version in original post...another arguement for adopting vb6
-
Jun 5th, 2000, 06:02 AM
#12
transcendental analytic
Str(Err) ? I don't like Str as it puts an extra space. You could avoid that with "" & Err
Use  
writing software in C++ is like driving rivets into steel beam with a toothpick.
writing haskell makes your life easier:
reverse (p (6*9)) where p x|x==0=""|True=chr (48+z): p y where (y,z)=divMod x 13
To throw away OOP for low level languages is myopia, to keep OOP is hyperopia. To throw away OOP for a high level language is insight.
-
Jun 5th, 2000, 05:33 PM
#13
PowerPoster
-
Jun 5th, 2000, 05:56 PM
#14
-
Jun 6th, 2000, 08:02 AM
#15
BruceG l stand corrected
Ok tested in vb5 sp3 and vb6 sp1, yeap your right MsgBox err & " : " & err.description does not generate an error. Therefore no need of Str(Err).
The problem l was getting was with our own ActiveX control which expects to get a string rather than numeric in a variable sMsg e.g sMsg = Str(Err) & " : " & Err.Description. This is used to display help messages and to generate a bug report form for our clients.
So you were right and l was wrong.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|