How to determine what statement is causing an error 1

[custsoft]

We know by using the OnError command we can determine what error occurred but don't know what statement in what procedure is causing it. Any help would be appreciated. Thanks. Joe.

 

[WaltLukeIII]

I have found that The easiest way is the use of messge Boxes with simple statments like "Right here after first if." is the easiest way to see what work is getting done and where problems start to occur.

Walt III
SAElukewl@netscape.net

http://www.muc.edu/~lukewl

 

[peekay]

If you know in which procedure it occurs you can halt at the beginning (inserting a stop or marking the line at the left) of the procedure and press F8 - this goes down the procedure one step at a time.

PK Odendaal
pko@mweb.co.za

 

[custsoft]

Thanks a lot for your replys. We are basically trying to debug a live application and all the user is seeing is the famous "run-time error". So I guess there is no way by using the OnError command to determine the exact statement that is causing it? Thanks again.

 

[rlgilby]

I have ran into the same situation. And what I have done using the OnError. I declare a string variable and give it a value of "A" and after each line that I think could be causing a problem I append the next letter of the alphabet to that string variable. And then in my error handling routine I display the string variable using msgbox. Or you can append the next letter of the alphabet after each line of code to give you the precise line of code right away.

 

[zeevgetner]

the best thing is using line numbers.

add each of your line a line number.

then when there is an error you can write:

debug.print erl

and then you will know what line caused the problem

line numers is a must in debuging a big application

 

[tedsmith]

I find it useful to have every procedure with an [ On Error Goto ] at each procedure start. At each Error Label I put a [ MsgBox Error(Err) & " in ProcedureName at line " & Erl ,16,"ERROR":Resume Next ]
This prints out the type of error and the procedure where the error is happening which generally gives you a better clue.
When you narrow it down you can then use line numbers in that procedure rather than in entire program. or put the On Error Goto half way in the procedure.
Dont forget to use On Error Goto 0 (zero) just before the Exit Sub of each procedure.

 

[swilliams]

If your customer is getting the error in the runtime exe, you should be able to recreate this in the design time VB project.
Then, if you go to "Tools" and "Options", on the "General" tab, set the option to "Break on all errors" and then when you run the program and get the error, instead of getting the message box, the program will break and show you the line of code that is giving the error.
Simon

 

[jeba]

While you are in development/testing, you can go to "tools/options/general" and click the "break on all errors" option.

Run the program in IDE with the "run" option.

VB will break and highlight any statement that causes an error.

Do not leave this on when you install for real.

You can also get detailed info this way:

on error resume next

--- your code
--

if err.number <> 0 then
msgbox &quot;error is: &quot; &amp; err.number &amp; &quot; &quot; &amp; err.description
err.clear
end if

This will catch the last error that occured, display the error number and the description of it, clear the error and continue.

 

[tedsmith]

Isnt it amazing how the little things can mean so much. Thanks for this info about the options, it will save me a lot of time in future.