Code line in error message

[John J.]

In an error message, is it somehow possible to show the line of code or the
code line number that causes the error, in order to quickly find where
things go wrong?

Thanks,
John

 

[Jeff Boyce]

Possible, yes. Insignificant effort, no.

If your code lines are numbered, you can get that. But you'd need to number
your code lines...

An alternate approach is to <break> when you get the error and look at which
line is causing it.

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[John J.]

Thanks Jeff,

Could you elaborate a bit further on how to number the code lines?

John

 

[Pete D.]

This might help you with debugging
http://support.microsoft.com/kb/165517/en-us

 

[John J.]

Thanks Pete.

The reason for my question is not so much for debugging when I'm developing.
I am hoping, when a user calls with an error message I can more easily
address where the problem might be. Seeing a sub or function name already
helps, but with large pieces of code a line number would be handy.

John

 

[John Spencer]

At the beginning of each line of code type a number. for example

10 On Error GoTo Err_cmdDuplicateCurrent

20 Set frmAny = Forms(strFormName)

30 If MsgBox("Duplicate the current record?", _
vbYesNo, "Duplicate") = vbYes Then

In your error code use something like the following
Msgbox "Error " & Err.Number & _
IIF(ERL<>0,": Line " & ERL & vbCrLf, vbCrLf) & Err.Description, _
,"modTestBed : sDuplicateCurrentRecord"


John Spencer
Access MVP 2002-2005, 2007-2008
The Hilltop Institute
University of Maryland Baltimore County

 

[John J.]

Thanks John. The ERL var led me to http://support.microsoft.com/kb/148358.
For it to work you need to add extra lines to your code, which makes the
code less readable. However, I may find a use in it.

Sub ErrorTest ()
Dim x as Integer ' Declare variable.
10: ' NEW LINE!!!
On Error Goto ErrorTest_Error
11: ' NEW LINE!!!
x = 5 / 0 ' Divide by zero error
12: ' NEW LINE!!!
Exit Sub
ErrorTest_Error:
Debug.Print "Error occurred in line #" & Erl
Resume Next
End Sub

John

 

[Douglas J. Steele]

Take a look at MZ Tools for a free add-in that will add numbers for you (as
well as much, much more)
http://www.mztools.com/v3/mztools3.aspx

 

[John J.]

Thanks, that looks promising. I just installed MZtools for MVB 6.0 (I work
with Access2003 and MVB 6.3). MZtools's help, uninstall, and website show in
the programs section but when I start the VB editor from within Access I
can't find MZtools in the tools section or anywhere else. I did a reboot but
no luck. I must be doing something wrong. Can you help me out?

John

 

[John J.]

I fount it. The FAQ gave me the answer, I had downloaded the wrong version.
John

 

[fredg]

Thanks, that looks promising. I just installed MZtools for MVB 6.0 (I work
with Access2003 and MVB 6.3). MZtools's help, uninstall, and website show in
the programs section but when I start the VB editor from within Access I
can't find MZtools in the tools section or anywhere else. I did a reboot but
no luck. I must be doing something wrong. Can you help me out?

John

Open any module to show the code.
There should be an Add-in tool button along with the usual VBA
buttons.
Check the Load on Startup check box.
Also...
Right-click on any tool bar. Add the MZ-10 tool bar.

Note: Setting the "Break on Unhandled Errors" to True in VBA Options
General will give the fastest and easiest way to determine where in
the code the error occurred. Almost no one bothers with line numbers
anymore.

 

[david]

WTF !!! Maybe in Access 1.x, but not that I remember in Access 2,
which that article also refers to.

a) You do NOT need to put line numbers on new lines.
b) You do NOT need to put colons on line numbers.
c) Even if you put colons on line numbers, they still work, and
d: Even if you put colons on line numbers, they don't need to be on new
lines.

The other thing I'd add is that you often see examples like this:

Sub ErrorTest ()
On Error Goto ErrorTest_Error

With the subroutine name duplicated in the catch label. That is
a waste of effort, makes it impossible to cut-and-paste your
error handlers, and gets out-of-date if you change your subroutine
name. It is a vague historic hang-over from when BASIC used
line numbers as a natural primary key, and the catch labels needed
to be numeric and unique.

Instead,

Sub ErrorTest ()
On Error Goto Catch
....
exit sub
Catch:
call myhandler(erl)
raise err
end sub


Capture the error line and keep raising the error until you get to
the top level calling function on a form, where you can return a
user interface notification instead of an internal error.

(david)

 

[John J.]

a) You do NOT need to put line numbers on new lines.

In A2003, when an error occurs in line number 10 (which is on the same line
as the code), the error message shows line number 0.

The other thing I'd add is that you often see examples like this:


With the subroutine name duplicated in the catch label. That is
a waste of effort, makes it impossible to cut-and-paste your

I agree and also work as your describe.

John

 

[John J.]

There should be an Add-in tool button along with the usual VBA
buttons.
Check the Load on Startup check box.
Also...
Right-click on any tool bar. Add the MZ-10 tool bar.

Note: Setting the "Break on Unhandled Errors" to True in VBA Options
General will give the fastest and easiest way to determine where in
the code the error occurred. Almost no one bothers with line numbers
anymore.

Thanks. Indeed, I never read about them on the newsgroups.

John

 

[david]

In A2003, when an error occurs in line number 10 (which is on the

as the code), the error message shows line number 0.

Remove the colons from the line labels, save, close, and decompile.

I don't think what you are seeing is actually corruption in the
normal sense, I think it is more like the behaviour when you
get "dao" instead of "DAO", that is, an error in the interface
rather a error in the compiled code, but it is caused by the
compiled line numbers getting out of sync with the display,
and it only happens when you are futzing around for the first
time. You may also see the problem where line numbers are
rejected as undeclared functions, leading you to put colons on
all of your line numbers.

But it only happens when you are futzing around for the first
time. Once you've started adding line numbers to your code
it will never happen again.

(david)