Error handling with line number

[John]

Hi

Is it possible to get from error handling the line number and/or the code of
the line that caused the error?

Thanks

Regards

 

[Allen Browne]

Is it possible to get from error handling the line number and/or the code
of the line that caused the error?

If your routine has line numbers (labels), use ERL to get the error line,
e.g.:

10 On Error Goto Err_Handler
20 Dim i As Integer
30 i = 4 / 0 'division by zero error
30 Exit Sub
Err_Handler:
Debug.Print ERL 'shows 30
Resume Next

Notes:
1. Adding labels (line numbers) to all lines will make the routine execute
more slowly.

2. If only some lines have labels, ERL will report the most
recently-encountered label.

 

[david]

1. Adding labels (line numbers) to all lines will make the routine execute

more slowly.

Not enough so that I ever noticed it: where did you get that?

In fact, now that I measure it, still not enough to notice:

1.53125 seconds with line numbers
1.53125 seconds without line number

of course sometimes it is faster with line numbers:
1.59375 'with line numbers
1.65625 'without line numbers

but that's just random jitter

(david)

 

[Allen Browne]

Thank you for challenging this, David.

It's actually been a very long time since I used ERL, but it appears you are
correct: there is no practical performance difference in recent versions of
VBA.

 

[Klatuu]

As an additional note to time testing. I found that if I run test on two or
three different versions of a procedure to test for performance advantage
that if all are really about equal and I call them from a sub or function,
the first one run will be faster. I don't know if that is just an anomoly,
but when I first noticed it, I tried it on some other routines and I tried
switching the orders of the calls around. But, regardless, the first
routine run would run the fastest and it would also have the fastest time
for itself - that is, if I run RoutineA in different orders with other
comparison routine, it would get its best time when run first.

I have no idea if this is documented elsewhere, but I would be curios to
know if anyone else has experienced this.

1. Adding labels (line numbers) to all lines will make the routine
execute more slowly.

Not enough so that I ever noticed it: where did you get that?

In fact, now that I measure it, still not enough to notice:

1.53125 seconds with line numbers
1.53125 seconds without line number

of course sometimes it is faster with line numbers:
1.59375 'with line numbers
1.65625 'without line numbers

but that's just random jitter

(david)

 

[david]

Yes, it's not entirely dependable.

I assumed that it was the memory handler.

You may remember that in old versions of MS BASIC, on old PC's,
you could get an abrupt slow down after running some continuous
code. The abrupt slow down was the time taken by the Garbage
Collector, to reclaim unused memory.

The VB garbage collector is probably a linear descendent. Less
noticeable now that PC's run faster, but still running as a periodic
task.

(david)

As an additional note to time testing. I found that if I run test on two
or three different versions of a procedure to test for performance
advantage that if all are really about equal and I call them from a sub or
function, the first one run will be faster. I don't know if that is just
an anomoly, but when I first noticed it, I tried it on some other routines
and I tried switching the orders of the calls around. But, regardless,
the first routine run would run the fastest and it would also have the
fastest time for itself - that is, if I run RoutineA in different orders
with other comparison routine, it would get its best time when run first.

I have no idea if this is documented elsewhere, but I would be curios to
know if anyone else has experienced this.

 

[Klatuu]

That is a reasonable theory. But regardless of the cause, when I am doing
any serious performance comparisons now, I run each routine at least 100
times varying the order of execution. Based on your post, I think I will
see what closing Access and reopening will do and just for fun, what
rebooting will do.

 

[david]

Closing Access has another effect -- it unloads the database
file from the file cache.

Doing database tests, I run do-events and dbengine.idle as well.

(david)

 

[Klatuu]

Both between each call?

Closing Access has another effect -- it unloads the database
file from the file cache.

Doing database tests, I run do-events and dbengine.idle as well.

(david)

 

[david]

It's been years since I actually ran any database tests other
than transactions -- the best part of the decade.

(david)