Error Trapping Code - Display Exact line that caused Error - Template for code

[Rx_]

MZ Tools is a free add-in that offers a Toolbar in VBA Editor - Add / Remove Line Number.
In my first version of BASIC in ROM on an Ohio Scientific single board computer (pre-dates Atari, Apple, and other PC) the 6502 Processor and BASIC required Line Numbers. One bad habit was to use a GOTO (Line Number).
The Line Numbers are not common to code today. For troubleshooting, they can play a valuable role.

Public Sub ErrorTrapUsingLineNumbers()
           Dim dblNumer As Double
           Dim dblRandomNumber As Double
           Dim MyAnswer As Long
10    On Error GoTo Hell
           ' A Random Crash to make it more dynamic is perscribed by Rx_
           ' Note: all random numbers will cause an error when divided by zero
           ' Howerver the randoem number will cause the error to oxxur at a different line number
           ' In VBA Editor window - A tool such as MZ Tools adds a Tool box with Add / Remove Line Numbers
           ' A developer can manuall add line numbers. They must be acending and not duplicates
20    dblRandomNumber = Rnd()
30    Select Case dblRandomNumber
       Case Is < 0.3
40       MyAnswer = 3 / 0
50     Case Is < 0.5
60       MyAnswer = 5 / 0
70     Case Is < 0.6
81        MyAnswer = 6 / 0 ' line numbers don't have to end in 0
90     Case Is < 0.9
100      MyAnswer = 9 / 0
110    Case Else
120      MyAnswer = 10 / 0
130        End Select
140    MsgBox MyAnswer, vbCritical, "Error prevents this from ever executing"
150   Exit Sub
      ' Code that finishes is above, bad code goes below
Hell:
160   MsgBox "Value: " & dblRandomNumber & vbCrLf & _
            "Error Line: " & Erl & vbCrLf & _
            "Error: (" & Err.Number & ") " & Err.Description, vbCritical, "Line Number where code caused Error"
End Sub

 

[CJ_London]

have seen this before but does it work with .mde/.accde or .accdr?

 

[Rx_]

Short answer: I actually don't know!
Since my application is in a sandbox a.k.a. Citrix, it runs in its raw naked form and just prevents the users from accessing design mode. With several releases a week, this saves a lot of time. Personally, I don't leave this in my production code. It is typically block commented out. But, it comes in really handy for pesky trouble issues.

This is the best article I could find on the subject - it includes a good introduction to intermediate and advanced Error Trapping.


https://msdn.microsoft.com/en-us/library/ee358847(v=office.12).aspx
That is an Excellent point!
First, this article starts by Pointing out:
"This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. "
That statement alone gives me the warm and fuzzy feeling?

About 80% down, the article addresses the line numbers error trapping.
Further down, when it discusses preparing the application for distribution, the need to add line numbers and/or remove Debug.Assert (and the other Stack pop features discussed in Advanced Debugging) is slightly mentioned.

Let me add the warning that using a Line Number to automatically link to a Document for the user is risky. The line numbers will change if code is added, removed or commented out. Oh, but they do mention 3 tools to help with that.