1. Coding practice for better user-proofing

Hello,
I hardly ever submit and my code to this forum, as its not up to the standard of persons such as the late Jiri Babor or David Cuny..
Thier code is efficient, readable, concise.. positively elegant IMHO! No disrespect to any others not mentioned is intended.
Anyway, I have a program with 43 possible parameters, being a mixture of singular / multiple arguments, numeric and text; several controls/edittexts in a GUI too. I short, lots of opportunity where this flexibility allows a user to find a bug/undocumented feature ;)
So I write a log of everything the user does, and copy the configuration file contents to the log also, including the assumptions for missing config parameters.
But, is there a better way to do something like this: 

function parse_sql_data(integer fieldnum, sequence data, 
         sequence sql_delimiter) -- find between delimiters, drop spaces 
  sequence s1, s2, delimiter, space 
  integer i1, i2, i3, i4 
  space = " " 
  delimiter = sql_delimiter -- "|" 
  i3 = 0 
  s1 = data 
if debug_level > 3 then 
	writelog("Debug 4 function 'parse_sql_data' called, using '" & 
	data & "'") 
	debug_reccnt = sprintf("%10d",{fieldnum}) 
	writelog("Debug 4 function 'parse_sql_data' called, field " & debug_reccnt) 
end if 
-- where debug_level 1 is terse, 2 is normal messages, 3 is debug without proc/function names or passed vars 
-- the rest of this function is removed.... writelog puts date/time in front too 
end function

Is there a more elegant way to create/use a user debug level..?
BTW, debug level > 2 is only available when sanctioned by myself.

Regards,
Alan

new topic     » topic index » view message » categorize

2. Re: Coding practice for better user-proofing

  • Posted by ghaberek (admin) May 11, 2015
  • 1520 views
fizzpopsoft said...

Is there a more elegant way to create/use a user debug level..?

Typically include a function called debug() and/or debugf() (like printf()) and let that function handle all the debugging nonsense. 

procedure debugf( sequence msg, object data ) 
 
    -- where debug_level 1 is terse, 2 is normal messages, 3 is debug without proc/function names or passed vars 
    -- the rest of this function is removed.... writelog puts date/time in front too 
    if debug_level > 3 then 
        writelog( sprintf(msg, data) ) 
    end if 
 
end procedure 
 
function parse_sql_data(integer fieldnum, sequence data, sequence sql_delimiter) -- find between delimiters, drop spaces 
 
    sequence s1, s2, delimiter, space 
    integer i1, i2, i3, i4 
 
    space = " " 
    delimiter = sql_delimiter -- "|" 
    i3 = 0 
    s1 = data 
 
    debugf( "Debug 4 function 'parse_sql_data' called, using '%s'", {data} ) 
    debugf( "Debug 4 function 'parse_sql_data' called, field %10d", {fieldnum} ) 
 
end function

-Greg

new topic     » goto parent     » topic index » view message » categorize

3. Re: Coding practice for better user-proofing

Yup... slap forehead here... let the called debug proc test for the debug level.
See why I don't post much code, it shows sometimes I can't see the wood for the trees!
Thanks!

new topic     » goto parent     » topic index » view message » categorize

4. Re: Coding practice for better user-proofing

  • Posted by jmduro May 12, 2015
  • 1501 views
fizzpopsoft said...

Is there a more elegant way to create/use a user debug level..?
BTW, debug level > 2 is only available when sanctioned by myself.

Hello Alan,

One upon a time, I used a function I called logMsg using a variable named debug_level. 

public integer  debugLevel = 0   -- 0=no debug, 1=debug file only, 2=debug_file and screen output 
 
------------------------------------------------------------------------------ 
 
public function dateStamp(sequence msg) 
-- prefixes the message by date and time for logging 
  sequence cur_date 
 
  cur_date = date() 
  return sprintf("%d-%02d-%02d %02d:%02d:%02d -> %s\n", { 
                             (cur_date[1] + 1900), cur_date[2], cur_date[3], 
                              cur_date[4], cur_date[5], cur_date[6], msg 
                            }) 
end function 
 
------------------------------------------------------------------------------ 
 
public procedure logMsg(sequence msg) 
-- records logs 
  if debugLevel>0 then 
    puts(f_debug, dateStamp(msg)) 
    flush(f_debug) 
  end if 
  if debugLevel>1 then 
    puts(1, dateStamp(msg)) 
  end if 
end procedure

Regards

Jean-Marc

new topic     » goto parent     » topic index » view message » categorize

5. Re: Coding practice for better user-proofing

Thanks,
I do it a bit differently. I only use the console if my logfile open, or last put returned -1;
The downside of that is that there is a console window always open behind my GUI. So I make WinMain big enough that its not seen ;)

What I wanted to do, was have a user debug function where that function tests the public variable of debug_level and outputs more or less debug detail to the logfile, depending on that debug_level value.
While I am there, I call date() and save the results as public too for other reasons. All I need to do, is to place my debug function call inside my other procs/functions, after private variables are set and before any branch/test code within that proc/function.
Maybe store all private and passed vars for the function/proc to be debugged, as a single sequence thats the argument to the debug call, not forgetting the name of the proc/function we are calling from. And finally in the user debug function will be a option of trace(1) - when I am desperate!

Regards,
Alan

new topic     » goto parent     » topic index » view message » categorize

6. Re: Coding practice for better user-proofing

  • Posted by petelomax May 13, 2015
  • 1423 views

Another trick I've started using recently is along the lines of logMsg("pemit2.e line 1443, ...").
Obviously the 1443 gets out-of-date pretty quickly, but you can easily search for it, in the right file.
Helps me out a lot on big complex apps when messages start appearing weeks or months after I added them.
The examples given are fine for debugging a single routine, but not really the whole process.

Pete

new topic     » goto parent     » topic index » view message » categorize

7. Re: Coding practice for better user-proofing

  • Posted by irv May 13, 2015
  • 1424 views

Some programming languages (I forget which ones at the moment) have a way to include the current line number in an error message. So your error lines could read printf(1,"Error in line ..."), using some variable containing the current line #. I wonder if such a capability could be added to Eu?

Hm... the thought occurs to me that crash() already has that information. Maybe that would be a starting point for writing such a routine.
Forked into: Logging tools

new topic     » goto parent     » topic index » view message » categorize

Search



Quick Links

User menu

Not signed in.

Misc Menu