Error trapping

[IanSmith]

Morning all,

I'm not sure if this has been covered, but today's coding expedition popped these suggestions into my head:

Error messages give the line number of the error. It's fun and games stepping through several hundred lines of code to find the bit that fell over. If the error message had giving the line number, it would have saved a bunch of time.

And on that thought - how about allowing small increments in the Trace field? Setting it to the minimum of one second means watching patiently for several minutes before we get to the meaty bit; if we could set the trace to fractions of seconds (perhaps to one decimal place) we could set a trace off, and then see where things went wrong.

Another thing (and yes, it was a bugtastic day, thanks for asking...) how about a trap command. This would jump to a certain part of the script whenever an error occoured so we could use the information or dump all the variables to a text file. For example;

Trap>errors
.
.
.
label>errors
writeln>c:\error.txt,result,%all_my_variables%

Thanks for listening, we now return you to your regular questions.

Ian

[Marcus Tettmar]

Great ideas, thanks. Version 8.0 has _DUMP_VARS setting which will dump all vars when required. We will definitely add line number to error messages (why haven't we done his already!) and I like the idea of running a subroutine on error. Like VB's on error goto statement ...

[Hardware_Tester]

I think, the first suggestion would be great *thumbs up*

The second one I did not understood fully but I think this can be done with the existing commands.

[pgriffin]

Ian,

Have you tried to set Breakpoints? Sounds like you might get some of what you want with that.

[IanSmith]

Yay!

The second request was a follow on from the first. At the moment, my current script is a nudge under 600 lines, and I got an error. In order to find the line that caused the error I had to step through many of those hundreds of lines to get to the nasty bit (which is a tad tedious, and even worse before I found the Trace command and did it with the F8 key!).

So, I set the trace interval to 1 second and sat back to watch the show. I have a couple of initialisation loops that took a few minutes each before the error in question popped up.

My request is that the trace interval be available in smaller increments. Setting the interval to 0.1 seconds would mean the script would speed through and helpfully stop at the very good example of shockingly poor coding. Every silver lining has a cloud.

Breakpoints would only help if I knew where the error was in the first place...

Incidently, you might be interested in my interim variable dump method that helped a lot; every time a variable was changed or created (such as reading a line of text from a file) I used writeln to push in into a file called c:\traplog.txt . Once the error stopped the script I could tail the traplog to see what the offending variable was and sort it out.

Take care, Ian

[Marcus Tettmar]

Breakpoints would only help if I knew where the error was in the first place...

But they can help you narrow it down. Instead of stepping through hundreds of lines of code to get to the "nasty bit", set a break point just before that nasty bit. Hit run and the macro will run at normal speed until it gets to that break point. Then you can step through the nasty bit and only the nasty bit.

Incidently, you might be interested in my interim variable dump method that helped a lot; every time a variable was changed or created (such as reading a line of text from a file) I used writeln to push in into a file called c:\traplog.txt . Once the error stopped the script I could tail the traplog to see what the offending variable was and sort it out.

Much easier to use TimeStamp for this. Also in v8.0 you can dump out all vars between each step just by setting _DUMP_VARS to 1