siyu
asked on
error handling
Dear Experts,
I copied the following code from MSDN, I suppose that On Error GoTo will avoid run-time error message box show up. But when I try to run the following code in debug mode line by line, run-time error message box still poped up, why? If error occurs in line 'Kill "myfile.txt"', why it didn't go to ErrorHandler?
Please help!
Option Explicit
Private Sub Command1_Click()
OnErrorStatementDemo
End Sub
Sub OnErrorStatementDemo()
Dim ObjectRef
Dim Msg As String
On Error GoTo ErrorHandler
Open "myfile.txt" For Output As #1
Kill "myfile.txt"
On Error GoTo 0
On Error Resume Next ' Defer error trapping.
ObjectRef = GetObject("MyWord.Basic") ' Try to start nonexistent
' object, then test for
'Check for likely Automation errors.
If Err.Number = 440 Or Err.Number = 432 Then
' Tell user what happened. Then clear the Err object.
Msg = "There was an error attempting to open the Automation object!"
MsgBox Msg, , "Deferred Error Test"
Err.Clear ' Clear Err object fields
End If
Exit Sub ' Exit to avoid handler.
ErrorHandler: ' Error-handling routine.
Select Case Err.Number ' Evaluate error number.
Case 55 ' "File already open" error.
Close #1 ' Close open file.
Case Else
' Handle other situations here...
End Select
Resume ' Resume execution at same line
' that caused the error.
End Sub
I copied the following code from MSDN, I suppose that On Error GoTo will avoid run-time error message box show up. But when I try to run the following code in debug mode line by line, run-time error message box still poped up, why? If error occurs in line 'Kill "myfile.txt"', why it didn't go to ErrorHandler?
Please help!
Option Explicit
Private Sub Command1_Click()
OnErrorStatementDemo
End Sub
Sub OnErrorStatementDemo()
Dim ObjectRef
Dim Msg As String
On Error GoTo ErrorHandler
Open "myfile.txt" For Output As #1
Kill "myfile.txt"
On Error GoTo 0
On Error Resume Next ' Defer error trapping.
ObjectRef = GetObject("MyWord.Basic") ' Try to start nonexistent
' object, then test for
'Check for likely Automation errors.
If Err.Number = 440 Or Err.Number = 432 Then
' Tell user what happened. Then clear the Err object.
Msg = "There was an error attempting to open the Automation object!"
MsgBox Msg, , "Deferred Error Test"
Err.Clear ' Clear Err object fields
End If
Exit Sub ' Exit to avoid handler.
ErrorHandler: ' Error-handling routine.
Select Case Err.Number ' Evaluate error number.
Case 55 ' "File already open" error.
Close #1 ' Close open file.
Case Else
' Handle other situations here...
End Select
Resume ' Resume execution at same line
' that caused the error.
End Sub
Last Comment
ASKER
Thank you for your reply, but file does exist, I got run-time error 55, so it should go to ErrorHandler to fix this error, then go back to the statement that causes the problem, right? But why it doesn't? How to avoid run-time error message box pop up?
ASKER
I just figured out that I didn't choose Tool->options..->general->
After I did this, run-time error message box doesn't pop up again.
After I did this, run-time error message box doesn't pop up again.
ah ok I was wondering because I looked at it wrong, but then couldn't find out why it was doing what you said it was....it worked fine for me
I always use On Error Resume Next for two reasons:
Firstly: If another error occurres along the way, you can just ignore it, instead of having VB come to a complete halt. This is of course a disaster when the program's been compiled.
Secondly: You can check for errors whereever you want. So if you want VB to always run some functions after a place where an error can occur or not, just do the error check behind that.
Anyway, silly that VB wants you to set up the Error Trapping.
Firstly: If another error occurres along the way, you can just ignore it, instead of having VB come to a complete halt. This is of course a disaster when the program's been compiled.
Secondly: You can check for errors whereever you want. So if you want VB to always run some functions after a place where an error can occur or not, just do the error check behind that.
Anyway, silly that VB wants you to set up the Error Trapping.
personally I can't wait until I can convert my projects to .Net because I prefer the whole try { } catch thing
That works quite well, too, although you can make this yourself using On Error Resume Next.
For example:
On Error Resume Next
Open "C:\file_doesnt_exist.txt"
Close #1
If Err.Number <> 0 Then
Debug.Print "Error: " & Err.Number
Err.Clear
End If
Is the same as Java's try {} catch:
try
{
//open the file, i'm not going to type this out
}
catch (Exception e)
{
System.out.println("Error:
}
For example:
On Error Resume Next
Open "C:\file_doesnt_exist.txt"
Close #1
If Err.Number <> 0 Then
Debug.Print "Error: " & Err.Number
Err.Clear
End If
Is the same as Java's try {} catch:
try
{
//open the file, i'm not going to type this out
}
catch (Exception e)
{
System.out.println("Error:
}
ASKER
Savvage,
Thank you for your comments. But by using On Error Resume Next, we only skip the error and can't fix the error(if it is fixable at run-time) and automatically go back to execute the statement that causes the error again, right?
Thank you for your comments. But by using On Error Resume Next, we only skip the error and can't fix the error(if it is fixable at run-time) and automatically go back to execute the statement that causes the error again, right?
ASKER CERTIFIED SOLUTION
THIS SOLUTION IS ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Visual Basic Classic
Visual Basic is Microsoft’s event-driven programming language and integrated development environment (IDE) for its Component Object Model (COM) programming model. It is relatively easy to learn and use because of its graphical development features and BASIC heritage. It has been replaced with VB.NET, and is very similar to VBA (Visual Basic for Applications), the programming language for the Microsoft Office product line.
165K
Questions
--
Followers
--
Top Experts
Get a personalized solution from industry experts
TRUSTED BY
If the error occurred in the sameprocedure as the error handler, execution resumes with the statement that caused the error. If the error occurred in a called procedure, execution resumes at thestatement that last called out of the procedure containing the error-handling routine.
So if the file doesn't exist in the first place you aren't capturing that error and are just returning without fixing it thus causing the error to occur again.