views:

125

answers:

2

If a run-time error occur in a VB6 app, does this mean Error handling has been turned off by use of the On Error Goto 0 statement?

Can this assumption be made? Or are there other circumstances in which a run-time error could occur?

If an error has been handled by either a Resume Next or a Goto then surely a run-time error would not occur. True or False?

A: 

It occurs because there is no error handler within the executing code, including calling procedures. You cannot make the assumption that On Error Goto 0 was used.

I am assuming you mean an unhandled run-time error. Since it is unhandled, your application "ends abnormally".

Visual Basic Concepts, Error Handling Hierarchy, http://msdn.microsoft.com/en-us/library/aa241677(VS.60).aspx

If an error has been handled by either a Resume Next or a Goto then surely a run-time error would not occur. True or False?

False. Sometimes a run-time error will occur in the error handler. If your error handling logic misses this, you will get an unhandled run-time error.


More Information

Briefly, using On Error Goto 0 removes any error handler (disables or turns off) within the procedure until the procedure ends or you assign an error handler using one of the On Error statements. User-Interface events with no error handling code will also have no error handler until you define one.

Error Trapping

During debugging, you can specify "Error Trapping" which causes VBE to break "on-all-errors", "in-class-module", or "on-unhandled-errors". During run-time, the behavior is "On Unhandled Errors" (A run-time error will occure if the Visual Basic Run-Time Library can find no error handler.). If you are troubleshooting / debugging, try setting "Error Trapping" to "Break on All Errors". This will cause VBE to break at the point of the error, where you can start debugging or just contine execution.

AMissico
When you say "False. Sometimes a run-time error will occur in the error handler", wouldn't this be an example of an error not being handled, which would mean the answer to the question is True?
Craig Johnston
I understand the question to mean that "once in the error handler a run-time error will not occur because I am already in an error handler." If that is the case, then the answer is False. If an error occurs in an error handler then the next error handler is the chain will handle this newer error. If there is no enable error handler then you will get an unhandled run-time error.
AMissico
A: 

If you are trying to sort out a problem, I recommend using a debugger to reproduce the error message, and then pause code execution and see where the error occurs. Check the call stack, look at variable values, and figure out how the error is happening.

  • Use the VB6 IDE if possible.
  • If the problem does not occur when using the VB6 IDE use another debugger, for instance Visual Studio 2008 Express Edition which is free.

There are several situations in which an error could occur. For example you could execute a code line that triggers an event to fire and be handled immediately, and the event handler might experience an error (if the event handler does not have error handling). Also sometimes VB6 runtime errors can be displayed when your app starts, before any of your code is executed.

MarkJ
A run-time error is being reported by a customer but I cannot reproduce it in my IDE. My only option is to put in error-handling.
Craig Johnston
@Craig That's one option. Another one is to add some logging to track down the error line. Another one, if you have access to the user's machine, is to use a free debugger like WinDbg or Visual Studio Express Edition. You might be able to use Remote Assistance or some such
MarkJ
@MarkJ: How can you log the error line ?
Craig Johnston
The only way to log the error line is to add line numbers. There are third-party utilities to do this but I do not recommend.
AMissico
@Craig Johnston: When trying to reproduce error are you running as user or as "power-user or administrator"? I suggest restricting your rights then test.
AMissico
@AMissic, @Craig I was thinking of logging to an external log(e.g. a file). Just sprinkle some messages like "Got to point A" or "Starting routine B". Ask the user to reproduce the error. Look at the messages to find out the rough area of the error. Add more messages to track down in more detail. Repeat until you know the exact line
MarkJ
@MarkJ: Yes, that is a valid troubleshooting technique. Especially, if the user is willing to do it.
AMissico