simple on error question

I just began playing around with error handling.
I have two questions.

One, in the code below.. i set it so that a message box appears on error
can anyone tell me why the message box pops up 2 or 3 times before it goes back to my program? Not 3 seperate message boxes.. but i click ok, it pops up again, click ok again, then it pops up again. and after a few times, it lets me go back to my program.

Second, would this be an okay way to just put this type of thing in every sub routine that i have so if any errors pop up, it just lets the user go back to the app and change whatever they messed up ?


Private Sub Command1_Click()
On Error GoTo 1
1 MsgBox "error occured"

Resume Next
Label8.Caption = DateDiff("n", Text1.Text, Text2.Text)

End Sub


if it matters..to cause the error, i enter a time of 100:00:00

Private Sub Command1_Click()
On Error GoTo 1
1 MsgBox "error occured"

Resume Next
Label8.Caption = DateDiff("n", Text1.Text, Text2.Text)

End Sub


You should put a breakpoint on line "1" and step through the sequence.

Basically, you come into the Click Event, and the first line you process
is line 1, so you bring up the msg box. Once you return from the
msgbox, you to a resume next, which brings you back to the line after
the On Error line, which is the message box again. After you return
from there you then continue to your DateDiff function, and create an
error, so you go back for a third time.

Normally, you put your error handling code at the end of the sub, and
put an exit sub in front of it, so you don't run in to the error handling
code by "running into it".


Private Sub Command1_Click()
On Error GoTo 1

Label8.Caption = DateDiff("n", Text1.Text, Text2.Text)

exit sub
1 MsgBox "error occured"
Resume Next

End Sub

OKay, thanks for that.. that works great, fixed a problem i didnt even notice right away.. but now, the only question left at the moment is.. is there a downside that i dont see from putting that in like every sub so that it just pops up a message box instead of dumping the program? and giving the user a chance to go back and take a second look at what they entered so they can fix it?

It depends on what type of error you are handling. If it is critical, then you have to take steps to remedy it or exit. If is non critical, you most likely can just ignore it, log it, or alert the user so they can fix it. Error handling is part of programming itself. You have to decide what to do in each situation.

--Van^

It depends on what type of error you are handling. If it is critical, then you have to take steps to remedy it or exit. If is non critical, you most likely can just ignore it, log it, or alert the user so they can fix it. Error handling is part of programming itself. You have to decide what to do in each situation.

--Van^

* * * *, i was afraid it was gonna be more complicated than I was hoping.
Well, what is defined as critical? like in this situation, im basically just trying to make sure they don't enter letters or a messed up time..
before, it would cause a type mismatch or some kind of error..shut down the program.
how would you determine the severity of different errors ?

Severity is defined by how the application will react to the error. For example, suppose you have an application that displays JPGs. Well, if the data that you are telling it to display isn't in JPG format, that's a fairly critical error. The application cannot perform what it was intended to perform. You have to recover from it gracefully. You might have to clean up some objects, or alert the user. Either way, you have to get the program to a state that it is stable. Now, on the other hand, if you have a function that is designed to delete a file. If the file doesn't exist, an error will be thrown when you execute Kill strMyFileName At this point, it doesn't matter. If the file doesn't exist, then there is no need to delete it. See the difference?

--Van^

Severity is defined by how the application will react to the error. For example, suppose you have an application that displays JPGs. Well, if the data that you are telling it to display isn't in JPG format, that's a fairly critical error. The application cannot perform what it was intended to perform. You have to recover from it gracefully. You might have to clean up some objects, or alert the user. Either way, you have to get the program to a state that it is stable. Now, on the other hand, if you have a function that is designed to delete a file. If the file doesn't exist, an error will be thrown when you execute Kill strMyFileName At this point, it doesn't matter. If the file doesn't exist, then there is no need to delete it. See the difference?

--Van^
hmm, well im kinda confused.. maybe because i havent seen these types of errors unhandled.. doesnt "on error" just make whatever i want to hapen based on ANY error that occurs? so that like right now, with what im doing.. the code in the previous post from passel works like a champ, does exactly what i wanted it to do. keeps the program from crashing and gives a second chance to go back and look at what was entered, to change it. wouldn't it do that no matter what error came up? lets say for your example that you want to delete a file that doesnt exist or u try to read a a file type that isnt expected.. say u select a media file when a text file is expected or something.. when the error occured.. if i set it to display a message box.. wouldnt the message box pop up and then go back to where u were before the error happened regardless of the type of error ?

An On Error statement will trap any error, yes, but only within that function/subroutine. Say I had a sub that deleted a file. There would be no need to trap and handle an error there. I could safely just do an On Error Resume Next within that subroutine. However, if I had a function that displayed a JPG, that's a critical error and I would have to handle the situtaion if any error is thrown. Now that that point is known, you can also check the error number and description on a lot of things to check for specific errors. Once you know a specific error might occur, you could check for it and handle it specifically. Say, for example, the file deletion example. If you don't have permission to delete the file, the file is locked, or some other issue, that is completely different from the file not existing. You have to handle those situations completely differently from the file not existing. So, you'd have to check the Err.Number or the Err.Description to find out what error was thrown and decide where to go from there.

--Van^

An On Error statement will trap any error, yes, but only within that function/subroutine. Say I had a sub that deleted a file. There would be no need to trap and handle an error there. I could safely just do an On Error Resume Next within that subroutine. However, if I had a function that displayed a JPG, that's a critical error and I would have to handle the situtaion if any error is thrown. Now that that point is known, you can also check the error number and description on a lot of things to check for specific errors. Once you know a specific error might occur, you could check for it and handle it specifically. Say, for example, the file deletion example. If you don't have permission to delete the file, the file is locked, or some other issue, that is completely different from the file not existing. You have to handle those situations completely differently from the file not existing. So, you'd have to check the Err.Number or the Err.Description to find out what error was thrown and decide where to go from there.

--Van^

okay, thanks a lot for your time.
I think i will try to find some more stuff to read about all this before asking anymore questions.
Thanks!