The joys of debugging and perfectible documentation - part 2

One of the pleasures of my job is maintaining a large VB6 app. In the due process of trying to nail a particulary nasty, seemingly almost random bug, I had to write a sort of post-mortem, error active x dll able to log some errors on a text file. Visual Basic 6 offers the Err Object, with its properties, Err.Description, Err.Source, Err.Number. And the Erl function. This function should give me the line of code that raises the exception. Too bad that in my logs this line is always zero.

It turns out that Erl works, but it only gives the label nearest to the incriminated line of code. And that's not all: it has to be a strictly numerical label. For example

traptheerror:

dim a as integer

a = "nope"

doesn't work

10:

dim a as integer

dim c as string

a = "nope"

works, but it's not that clear. This one is even better (and I recommend this to make it so)..

10 dim a as integer

20 dim c as integer

30 a = "nope"

Shades of the early eighties, maybe that's why it wasn't clearly mentioned in the official docs. But one shouldn't use a decade old IDE anyway..