Macro for error testing

[Gösta H. Lovgren-2]

Here is a really simple quick easy Macro for Error testing. Just insert an "Err_Msg" anywhere in the code. If an Err gets generated, the macro will tell you the Function/Sub name. Then you can start more intensive "If Err Then" trapping in that Function/Sub.

'       
Macro Err_Msg 
 If Err Then
   ? Using$("# ", Err) & Error$(Err), %MB_TASKMODAL, FuncName$ 
 End If 
End Macro 
'

======================================
"The mistakes are all waiting to be made."
chessmaster Savielly Grigorievitch Tartakower (1887-1956)
on the game's opening position
======================================

[Guest]

.
A debug flag can help:

%DEBUG_FLAG 1   '0
'       
Macro Err_Msg 
#IF %DEBUG_FLAG
 If Err Then
   ? Using$("# ", Err) & Error$(Err), %MB_TASKMODAL, FuncName$ 
 End If 
#ENDIF
End Macro 
'

This one also helps:

MACRO ifdbgx(x)
#IF %DEBUG_FLAG
x
#ENDIF
END MACRO
'
'
'use as follows:

ifdbgx(? funcname$ + " so far so good")

From the docs, it is not clear for me what get priority at compile time, #IF..#ENDIF or macros. I wrote this one when having different named debug flags in different files, but it seem compiler get confused:

MACRO ifdbg=#IF %DEBUG_FLAG
MACRO endifdbg=#ENDIF
'
'
'then:
'
     ifdbg
     'debug block here
     '
     endifdbg

'Tried:
'MACRO ifdbg=#IF %DEBUG_FLAG
'MACRO ifdbg
'#IF %DEBUG_FLAG
'END MACRO
'
'same result

Macros are great anyway

Regards, GdS

[Gösta H. Lovgren-2]

That is a good idea, Gus. I use something just like that for setting up a trace file. I hadn't thought of using a Constant as as flag though.

What I like about the Err_Msg Macro is no flags have to be set first and no variables declared. It can be just dropped in anywhere when programming. Really simple (only 7 characters to type) and uh... "basic". {grin}

=========================
"By a continuing process of inflation,
government can confiscate,
secretly and unobserved,
an important part of the wealth
of their citizens."
John Maynard Keynes
=========================

[Cliff Nichols]

I need to try it out still, but I LOVE the idea...I had not thought about it, I had started adding an "On Error ---Do Something" concept and it has been bugging me that I could not do a global "On Error" without adding lines of code to each and every routine, so this may be a better route.

When I try it out, it may well lead me to understanding Macro's (Which I do not enter unless 'record and play' in areas like excel etc...and not knowing how/why they work)

Either way...gut says "EXCELLENT TIP"

[Michael Mattias]

If you have to type the MACRO name to test anyway, pray what "labor savings" do you get by typing 'err_msg' instead of "IF ERR THEN err_msg" or something like that?

BTW, as long as you are using a multi-line MACRO, let me suggest ERRCLEAR belongs in that MACRO somewhere to clear the current error so it doesn't report the same error at the next test.

MCM

[Kerry Farmer]

My version of this macro is designed for user use as well.

So, I print a full screen with all the error data as you do but so a user can quote the error type etc.

I print all my contact details

I also print the following.....


PRINT "Dynamic Intelligence will pay a commission based on a substantive percentage
PRINT "of any extra licence fee received as a result"
PRINT "of any reported breach of Dynamic Intelligence's licence agreement"
PRINT
PRINT "Program will now exit automatically - Press any key to continue"

I thought that illegal use of my program is quite likely to generate run time errors and so I took this approach.

[Michael Mattias]

>I thought that illegal use of my program is quite likely to generate run time errors

Huh?

I realize we are two people separated by a common language, but in either Yank English or Kiwi English that has got to be Latin: non-sequitur.

[Kerry Farmer]

>I thought that illegal use of my program is quite likely to generate run time errors

Huh?

I realize we are two people separated by a common language, but in either Yank English or Kiwi English that has got to be Latin: non-sequitur.

Michael

Slackness in written exactitude is unforgivable - so I do not even ask your forgiveness.

Let me explain in good kiwi english....

Most errors at run time occur because of some environmental problem or change ie someone tries to run a program which is looking for a file which does not exist - probably the most common example.

I check all file oriented statements for runtime errors as part of the file operation, always. It is a huge help in testing and quite often all I need to know to solve a legitmate user's problem.

eg
Open a file then check for error
Read a file then check for error
Close a file then check for error

So if someone is having an illegal fiddle with my program then an environmental error is quite likely to happen. And the message shows.

Thanks mate, you're a good joker (joker = man!)

[Michael Mattias]

I have run-time errors from some perfectly legal uses:

1. The guy who decided on his own hook to just "add a couple of columns to a couple of tables in your database" and then wondered why the program would not INSERT new rows any more. (Generated trapped error from ODBC manager).

2. You think that was bad.. one guy selected a database.. at which time I connect to it (collecting the password if necessary), validate it has all the correct tables with all the correct columns in the correct order... and disconnect, saving the connection string to reconnect when I need access. Works great.

But.....while the user was doing something else, someone else went into his system and .. no, they did not simply change the password... they DELETED THE ENTIRE DATABASE. (*.mdb).

Program caught the error, but since it was one of those errors which 'cannot occur, ever" he got an error message which read "This can't happen" (I have since cleaned up that particular error message).

Had he merely changed the password, he would have gotten a nice formatted error message telling him I was unable to reconnect to the database.

But I guess that's why users are generally OK with paying a reasonable annual fee for support.. because <Stuff> Happens.

MCM

[Gösta H. Lovgren-2]

If you have to type the MACRO name to test anyway, pray what "labor savings" do you get by typing 'err_msg' instead of "IF ERR THEN err_msg" or something like that?

One savings is not having to type "IF ERR THEN "

BTW, as long as you are using a multi-line MACRO, let me suggest ERRCLEAR belongs in that MACRO somewhere to clear the current error so it doesn't report the same error at the next test.

MCM

Dunno about you but there is an ErrClear at the top of my Subs/Functions. However if one wanted there's no reason ErrClear could not be included the Macro as well. A good idea even.

=================================
"I'm not going to get into the ring with Tolstoy."
Ernest Hemingway (1899-1961)
=================================