Probably Silly question Error handling

1. In anticipation of moving from V2 directly to SBNG, I need a better 
error handling method.  Primarily, to actually fix stupid errors from 
happening as opposed to current my method of quick work arounds until I 
have time to actually figure the real source of the problem (always my 
poor programming skills).

2. I currently use ON ERROR goto err: kind of thing, it is my only use 
of GOTO.  At "err", I have your basic

Select CASE ERRNO
CASE 1: do something
CASE 2:  do something
etc.

Every couple of years, I "articulate" (my term) the process, where I 
keep track of how many Errors get thrown by error number in a database,
and then see what exactly I've fixed for good or never have been a 
problem then and get rid of those CASE statement and what is causing the 
most problems and try to work on those.  Obviously its always a Pareto 
distribution, the vital few vs. the trivial many. **(digression below)

What I'd really like to do is find out programmatically the particular 
code that causes the problems.  Because I'm not a developer, I don't 
have time to be screwing around with debugging every time some error is 
thrown but "fixed" with some quick fix I made years/months/a decade
ago.
To that end, the process would be much more efficient, if I could get at 
the HISTORY section in the debugger.  In V3/classic, I case see from the 
DEMO version that there is an .ini that keeps track of the HISTORY.  But 
I'm not using V3.

Nonetheless, even in SB2, the history has got to be stored someplace 
otherwise I wouldn't be able to see it in the debugger.  I thought that 
I saw a method to do this, many years ago probably in Compuserve forum, 
but I can seem to find it.

Any old code out there?  Thank you for assistance and consideration.

JDK

**(By the way, every now and then, I "articulate" my subs to find out

what is actually being used in the office.  I haven't' done it for a 
while.  If it didn't too greatly impact on performance, I'd think that 
having this as routine part of SBNG would be an important part of a RAD 
tool.  The idea is sometimes programmers/developers/users think they 
need a function but then it really never gets used.  Sometimes this is a 
lack of training (users just don't know about the bell or whistle), 
sometimes what the programmer thinks is cool the end users don't, 
sometimes lack of use is masking the fact that the bell or whistle 
actually doesn't work the way people thought it would, sometimes it 
doesn't really work at all, sometimes change happens and what was a neat 
bell or whistle in 1998, is of little utility in 2007!  Just a thought 

John,

Do you want to (a) "profile" your code, that is, print out a file that
lists each function call, with things like elapsed time, variable contents,
etc.? and/or (2) apply an error handler that fixes what can be fixed on the fly
(such as missing indexes or even fields) and writes a log file of what else
happens, with program line, date and time, error number and description, etc.?

Peter



On Thu, 03 May 2007 08:37:33 -0600, Kromkowski <kromkowski@verizon.net>
wrote:

> 1. In anticipation of moving from V2 directly to SBNG, I need a better
> error handling method.  Primarily, to actually fix stupid errors from
> happening as opposed to current my method of quick work arounds until I
> have time to actually figure the real source of the problem (always my
> poor programming skills).
>
> 2. I currently use ON ERROR goto err: kind of thing, it is my only use
> of GOTO.  At "err", I have your basic
>
> Select CASE ERRNO
> CASE 1: do something
> CASE 2:  do something
> etc.
>
> Every couple of years, I "articulate" (my term) the process,
where I
> keep track of how many Errors get thrown by error number in a database,
> and then see what exactly I've fixed for good or never have been a
> problem then and get rid of those CASE statement and what is causing the
> most problems and try to work on those.  Obviously its always a Pareto
> distribution, the vital few vs. the trivial many. **(digression below)
>
> What I'd really like to do is find out programmatically the particular
> code that causes the problems.  Because I'm not a developer, I don't
> have time to be screwing around with debugging every time some error is
> thrown but "fixed" with some quick fix I made years/months/a
decade ago.
> To that end, the process would be much more efficient, if I could get at
> the HISTORY section in the debugger.  In V3/classic, I case see from the
> DEMO version that there is an .ini that keeps track of the HISTORY.  But
> I'm not using V3.
>
> Nonetheless, even in SB2, the history has got to be stored someplace
> otherwise I wouldn't be able to see it in the debugger.  I thought that
> I saw a method to do this, many years ago probably in Compuserve forum,
> but I can seem to find it.
>
> Any old code out there?  Thank you for assistance and consideration.
>
> JDK
>
> **(By the way, every now and then, I "articulate" my subs to find
out
> what is actually being used in the office.  I haven't' done it for a
> while.  If it didn't too greatly impact on performance, I'd think that
> having this as routine part of SBNG would be an important part of a RAD
> tool.  The idea is sometimes programmers/developers/users think they
> need a function but then it really never gets used.  Sometimes this is a
> lack of training (users just don't know about the bell or whistle),
> sometimes what the programmer thinks is cool the end users don't,
> sometimes lack of use is masking the fact that the bell or whistle
> actually doesn't work the way people thought it would, sometimes it
> doesn't really work at all, sometimes change happens and what was a neat
> bell or whistle in 1998, is of little utility in 2007!  Just a thought
> about quality control and continuous improvement methods.)
>

Phil Alexander wrote:
> v2 doesn't have the call stack available the way v3 does, but in its 
> simplest form you can set a local "proc$" variable in each
routine and 
> output this variable with your error log.
> 
> Slightly more sophisticated is to use a global call stack array (or 
> possibly string) with push/pop procedures.

Huh?

OK I guess I can do something like this:

SUB main()
  GLOBAL SubArray$(3),CalledArray$
  SubArray$(0) = "main()
  SubArray$(1) = "Sub1()"
  SubArray$(2) = "Sub2()"
  SubArray$(3) = "Sub3()"
  CalledArray$ = "main()"
  REQUEST CalledArray$
  CalledArray$ = Subarray$(1)
  CALL Sub1()
  REQUEST CalledArray$
  CalledArray$ = Subarray$(2)
  CALL Sub2()
  REQUEST CalledArray$
  CalledArray$ = Subarray$(3)
  CALL Sub3()
  REQUEST CalledArray$
  CalledArray$ = Subarray$(1)
  Execut$ = "CALL " + Subarray$(1)
  EXECUTE Execut$
  END SUB

SUB Sub1()
  REQUEST CalledArray$
  CalledArray$ = SubArray$(0)
  END SUB

SUB Sub2()
  REQUEST CalledArray$
  CalledArray$ = SubArray$(0)
  END SUB

SUB Sub3()
  REQUEST CalledArray$
  CalledArray$ = SubArray$(0)
  END SUB

But shouldn't I be able to directly access the HISTORY (it has to be 
stored someplace internal to SB2)like maybe by a call to SBDATA.dll?

SB can send it to the status line, can I redirect the status line to a 
file or something?

JDK

John,

For function call history (for SB 3x)...

I pulled this from my working code. I can turn it on, and calls embedded in
every function write to the global variable gHISTORY$() for later processing.
This (with other functions I can dig out for you) can deliver a report that
lists all calls, indented according to order and dependencies, with the elapsed
time for each, and so on. This permits you to discover where in your app the
bottlenecks are.

You have to embed a call to this function in each other function, something my
code librarian (another sbl proggie) does when I generate the code for
profiling.

You can find the functions you want in here, like

  FILLARRAY Hist$,7

-which loads Hist$ with the last-called function names since Process().


Regarding error handlers, I think my old universal one is in the libraries
around the SB boards somewhere, but if you don't see it let me know.



   ' ******************************
   ' level 1: just print first functions called from process()
   ' level 2: include all functions called during the session
   ' level 3: include proctimer data
   ' ******************************
SUB CalHist()
  DIM LogFile$
  LogFile$ = HOMEDIR$ + "CALLS.LOG"
  IF EXISTS (LogFile$) THEN
    DIM dd$,z%,i%,t$,a$,lt$,indent%,done%%,h1$,h2$,ok%%,level%%,abort%%
    DIM Hist$(500)
    FILLARRAY Hist$,7
    WHILE NOT done%%
      IF (Hist$(i%) = "") THEN END WHILE
      indent% = i%
      i% = i% + 1
    WEND
    h1$ = Hist$(1):h2$ = Hist$(2)
    level%% = gLogLevel%%
    SELECT CASE level%%
    CASE 0
      ok%% = - 1
    CASE 1
      IF (indent% = 3) THEN ok%% = - 1
    CASE 2,3
      lt$ = ProcTimer$(indent%,h1$,h2$)
      ok%% = - 1
    END CASE
    IF ok%% THEN
      IF (gHISTINC% >= COUNT gHISTORY$) THEN REDIM gHISTORY$(gHISTINC% + 1)
      IF (gTIM% <> 0) THEN
        t$ = TIME$ ( NOW ,"hh:mm:ss.s") + SPACE$ (4) + TIME$ ( NOW -
gTIM%,"hh:mm:ss.s")
      ELSE
        t$ = TIME$ ( NOW ,"hh:mm:ss.s")
      END IF
      gTIM% = NOW
      IF (gSTARTTIM% = 0) THEN gSTARTTIM% = NOW :a$ = "start clock"
      gHISTORY$(gHISTINC%) = PAD$ ( STR$ (indent%,"999"),4) + PAD$
(t$,30) + PAD$ (lt$,35) + REPLICATE ("| ",i%) + h1$ + " (" +
h2$ + ") " + a$
      gHISTINC% = gHISTINC% + 1
      IF (gHISTINC% >= COUNT gHISTORY$) THEN REDIM gHISTORY$(gHISTINC% + 1)
    END IF
  END IF
  END SUB





On Thu, 03 May 2007 11:25:40 -0600, Kromkowski <kromkowski@verizon.net>
wrote:

> Phil Alexander wrote:
>> v2 doesn't have the call stack available the way v3 does, but in its
>> simplest form you can set a local "proc$" variable in each
routine and
>> output this variable with your error log.
>>
>> Slightly more sophisticated is to use a global call stack array (or
>> possibly string) with push/pop procedures.
>
> Huh?
>
> OK I guess I can do something like this:
>
> SUB main()
>   GLOBAL SubArray$(3),CalledArray$
>   SubArray$(0) = "main()
>   SubArray$(1) = "Sub1()"
>   SubArray$(2) = "Sub2()"
>   SubArray$(3) = "Sub3()"
>   CalledArray$ = "main()"
>   REQUEST CalledArray$
>   CalledArray$ = Subarray$(1)
>   CALL Sub1()
>   REQUEST CalledArray$
>   CalledArray$ = Subarray$(2)
>   CALL Sub2()
>   REQUEST CalledArray$
>   CalledArray$ = Subarray$(3)
>   CALL Sub3()
>   REQUEST CalledArray$
>   CalledArray$ = Subarray$(1)
>   Execut$ = "CALL " + Subarray$(1)
>   EXECUTE Execut$
>   END SUB
>
> SUB Sub1()
>   REQUEST CalledArray$
>   CalledArray$ = SubArray$(0)
>   END SUB
>
> SUB Sub2()
>   REQUEST CalledArray$
>   CalledArray$ = SubArray$(0)
>   END SUB
>
> SUB Sub3()
>   REQUEST CalledArray$
>   CalledArray$ = SubArray$(0)
>   END SUB
>
> But shouldn't I be able to directly access the HISTORY (it has to be
> stored someplace internal to SB2)like maybe by a call to SBDATA.dll?
>
> SB can send it to the status line, can I redirect the status line to a
> file or something?
>
> JDK
>
>
>
>
>
>
>

v2 doesn't have the call stack available the way v3 does, but in its  
simplest form you can set a local "proc$" variable in each routine and
 
output this variable with your error log.

Slightly more sophisticated is to use a global call stack array (or