views:

259

answers:

4

How would you prevent chunks of debugging code from accidentally leaking into production enviroment when using Progress 4GL?

+1  A: 

Similar to my other answer about the assertions, you can setup an include that will be empty on production sites containing the debug flag. On development sites you just need to define the value so that your debugging code is included in your program.

By wrapping code in a preprocessor the compiler will omit the debug code altogether when you compile it onto a production site.

&if defined( debugalert ) <> 0 &then
&endif

You would then use the "&global-define debug" in versions of the code you want to contain the debug code. Not defining "debug" should cause the compiler to omit the code.


/* debug.i omit the following on production */

&GLOBAL-DEFINE DEBUGALERT


/* test.p */ {debug.i}

DEF VAR h_ct AS INT NO-UNDO

DO h_ct = 1 TO 10:

&IF DEFINED( DEBUGALERT ) <> 0 &THEN

    MESSAGE "debug message" h_ct.
    <debug code goes here>

&ENDIF

END.

DuStorm
DuStorm, thanks, great solution however it requires an extra include file.
Totophil
A: 

If your test database and production databases have different names, you could use this code:

IF DBNNAME = "TESTDB" THEN
DO:
  <DEBUG CODE>
END.
Kevin Rettig
A: 

A solution is based on the assumption that development enviroment has a unique propath entry that is not available in other enviroments and code is recompiled when moved over:

&IF DEFINED(DEBUGGING) = 0 &THEN
    &IF PROPATH MATCHES '*development*' &THEN 
        &GLOBAL-DEFINE DEBUGGING TRUE
    &ELSE
        &GLOBAL-DEFINE DEBUGGING FALSE
        &MESSAGE Remove debugging: search for DEBUG within the code. 
    &ENDIF        
&ENDIF                                

&IF DEFINED(DEBUGGING_STARTED) = 0 &THEN
    &GLOBAL-DEFINE DEBUGGING_STARTED TRUE
    IF {&DEBUGGING} THEN
    DO:
&ELSE
    END.
    &UNDEFINE DEBUGGING_STARTED
&ENDIF

Usage

Save file as "debug" (without extension) to a directory pointed at by propath, then:

{debug}

 /* some debugging code here */

{debug/}
Totophil
+4  A: 

I usually just publish a special event - debug-message. In my dev environment there's a menu item in the application which will fire up a window which susbscribes to debug-message anywhere and displays any messages generated. So I can insert debug-messages into my code and then open the window if I want to see the messages. If I forget to tidy up the debug code then the live users don't see any messages, although I can still open the debug window to see what's going on.

( The webspeed version of this would just write the output to an OS file )

Gordon Robertson
Gordon, sounds like a very neat idea for logging on demand, thanks!
Totophil
I like this because you can have multiple listeners, one of which can be a logging function
nwahmaet