1. Coding practice for better user-proofing
- Posted by fizzpopsoft May 11, 2015
- 1598 views
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
2. Re: Coding practice for better user-proofing
- Posted by ghaberek (admin) May 11, 2015
- 1595 views
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
3. Re: Coding practice for better user-proofing
- Posted by fizzpopsoft May 11, 2015
- 1609 views
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!
4. Re: Coding practice for better user-proofing
- Posted by jmduro May 12, 2015
- 1577 views
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
5. Re: Coding practice for better user-proofing
- Posted by fizzpopsoft May 12, 2015
- 1550 views
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
6. Re: Coding practice for better user-proofing
- Posted by petelomax May 13, 2015
- 1499 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
7. Re: Coding practice for better user-proofing
- Posted by irv May 13, 2015
- 1499 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