Line Number and Error Handling

[dynamictiger]

I am reworking my error handler to better help me identify the error location. According to a couple of books I own you can add line numebrs to your procedures and modify your error handler to return the line number. They then go on to say that this is well documented on the web and that you can search there for examples and code. Really?

I have been looking at how to add the line numebrs and found several tools to do this. But how do I get the line number of the failed line in the error handler?

 

[WayneRyan]

dynamic,

You don't really want to go down that road.

Anyway ERL holds the error line #.

Wayne

 

[dynamictiger]

You don't really want to go down that road.

Why not? This seems to be a prefered solution where you have numerous recordsets each dependant on the last?

 

[Mile-O]

What's a recordset got to do with the line an error occurred on?

 

[dynamictiger]

Lets say ytou have a number of interdependant recordsets in module called MyModule.

An error occurs. Using other methods you can return the module name MyModule. Whta you really want to know is where in the module the error occured, so you can focus on the offending recordset. The error may not have generated in the first recordset, it could easily have generated in the second or third. The module name and error number are not going to help you much.

 

[WayneRyan]

dynamic,

In normal handling of recordsets, you can trap for
known (expected) errors and provide information for
errors that occurr unexpectedly.

Dim dbs As Database
Dim rst As DAO.Recordset
Dim sql As String
Dim Phase As String

On Error GoTo ErrorHandler

Set dbs = CurrentDb
'
' First Recordset
'
Phase = "RecordSet YourTable"
sql = "Select * From YourTable Where YourID = " & Me.YourID
Set rst = dbs.OpenRecordset(sql)
' Trap for known error ...
If rst.EOF And rst.BOF Then
   MsgBox("There are NO records in YourTable.")
End If
' Trap for known error ...
While Not rst.EOF and Not rst.BOF
   ' Do some Code
   rst.MoveNext
   Wend

Set rst = Nothing
'
' Second Recordset
'
Phase = "RecordSet OtherTable"
sql = "Select * From OtherTable Where YourID = " & Me.YourID
Set rst = dbs.OpenRecordset(sql)
' Trap for known error ...
If rst.EOF And rst.BOF Then
   MsgBox("There are NO records in OtherTable.")
End If
' Trap for known error ...
While Not rst.EOF and Not rst.BOF
   ' Do some Code
   rst.MoveNext
   Wend

Set rst = Nothing

Exit Sub
'
' Trap for unexpected (fatal) error ...
'
ErrorHandler:
   MsgBox("Unexpected error " & ERR & " while processing " & Phase & ".")
   Exit Sub

End Sub

Wayne

 

[ChrisO]

Since I was a bit bored and hadn’t used line numbers for about 20 year I had to have a play.

This code seems to indicate that we can’t always rely on Erl() returning the correct line number.

Sub Test()
    Dim lngX As Long
    
    On Error GoTo ErrorHandler
    
1
2
3   lngX = 1 / 0
4
5

ExitProcedure:
    Exit Sub
    
ErrorHandler:
    MsgBox Erl()
    Resume ExitProcedure
    
End Sub

Using line numbering may have its advantages but also comes with some subtle errors of its own.

I don’t know if this is just in VBA or if it was the same in GW Basic, too long ago, but thought I would mention it anyway.

Regards,
Chris.