Announcement

Collapse
No announcement yet.

PGM-CTR errors

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Luther
    replied
    Now ..

    You are right. I have a rudementary routine now that tells me
    the Error Number and Line Number (if there is one).
    as you do this, think about one more step. Even if you do not have
    a hard Line Number in view of (if there is one.), there is one
    more thing you can do.

    You can carry an otherwise not used integer variable that is
    set to what might have been a line number at various points in
    your program!

    It doesn't have to be a for-real line number.

    You just keep making it larger and larger, just line line numbers
    only just like

    Code:
    LABLE1:
    
            LNR% = 1
    
    LABLE2: 
    
            LNR% = 2
    Then if something blows up between LNR% = 1 and LNR% = 2, you just
    look at the value of LNR% and that takes the place of the formal
    line number in the error trap routine! If at the time the error
    takes place the value of LNR% is equal to one (1), you have your
    conditional answer on what label you should return to on RESUME.

    The error happened somewhere between LNR% = 1 and LNR% = 2.

    Takes the place of formal line numbers, kind of!

    Of course PB does the work for you with numeric labels. But the
    point is that the logic process on how this works may come in
    very handy when you might want to consider error trapping in other
    than raw PB code .. in assembler .. or C or whatever!

    If you know how to use line numbers for choosing the place to which
    you wish to RESUME in BASIC, that's one thing. But if you understand
    the process by which this works, you can immediately jump to the
    same or at least similar capability in other ways. And that goes
    not only to the process of error happenings, but the whole basic
    process of IF / THEN on which error trapping is just a specialized
    sugar coated variation on the theme.



    ------------------
    Mike Luther
    [email protected]

    Leave a comment:


  • Robert E. Carneal
    replied
    From Michael:

    .. and don't check ERR after each possible ERR-generating
    statment, you are (IMPO) trolling for trouble.


    You are right. I have a rudementary routine now that tells me the
    Error Number and Line Number (if there is one).

    Robert

    ------------------

    Leave a comment:


  • Michael Mattias
    replied
    ERL reports the most recently numbered line executed.
    ERRADR reports the "pgm-ctr" which you can then use to find the line of source code.

    Compile/Find Error is such a really cool feature of the DOS compiler; it should get more use.

    RESUME NEXT?

    If you use ...
    Code:
     ON ERROR ERROR RESUME NEXT
    .. and don't check ERR after each possible ERR-generating statment, you are (IMPO) trolling for trouble.


    Better you should write your code for development with ...
    Code:
    ON ERROR GOTO somewhere
    ..and after you have the major errors out and have code in place where ERR is EXPECTED (i.e., disk not ready, file not found), recompile, changing 'GOTO somewhere' with RESUME NEXT.

    MCM


    Leave a comment:


  • Doris Leeyin
    Guest replied
    Robert,
    You don't need to number all Lines, only those you suspect
    a problem, like the one on "SHELL".

    ------------------

    Leave a comment:


  • Robert E. Carneal
    replied
    Michael- You are right about RESUME NEXT being risky. Blame my
    college professor. Her opinion, at the time anyway, was to
    track on paper what errors you wanted to catch. Then write
    +only+ for those. Assume I have written a routine for the
    errors I want to trap, then my next statement after the error
    point would go back to "default" values for the variables so
    the program could continue. I thought it was risky and asked
    her if it wasn't better to prepare for all errors? Her response?
    "Do it my way for the grade. I like RESUME NEXTs, and you will
    too!" It is a habit I am working on breaking.

    Doris, thank you for pointing out using line numbers. Previously
    I was NOT a line number user due to the fact my Quickbasic did
    not allow line numbers in SELECT CASE statements? I was pleased
    to find that not the case with PB. Now I got to number all my
    routines now.

    ------------------

    Leave a comment:


  • Doris Leeyin
    Guest replied
    Sorry, I forget to tell you can use "PRINT ERR,ERL" to check code

    ------------------

    Leave a comment:


  • Doris Leeyin
    Guest replied
    PB supports Line Numbers, put a Line Number in front of each Line
    and break the code smaller in each line, then use on error goto
    and check the error code then use resume (resume next is risky)

    ------------------

    Leave a comment:


  • Mike Luther
    replied
    But wait!

    Isn't there more here? Grin!

    RESUME NEXT has a price tag, doesn't it? If you use it you
    generate a larger finished product as to the operational size
    of your program, no? Next means the code has to know where next
    is, as I understand all this.

    As well, I may be learning something here again too, but isn't
    the whole intrinsic error level operation keyed to NUMERIC line
    labels?

    I think I've learned a long time ago that an error only romps
    back to the closest NUMERIC line label. For code stability
    purposes I've never asked an error routine to ever even return
    to a non-numeric line label. At least in BASIC. Can PB RESUME
    at a non-numeric label? I think so, but it doesn't trap an
    error to same as far as I know.

    I wish it did in some further incantation of whatever, but I'm
    not holding my breath or an avoidance on that wish.

    That said, if I have to have error trap location information
    in a block of code which doesn't have numeric line lables, I
    create my own numeric trace variable pointer as the block
    executes. Sort of my own line numbers if you please. Then
    on error I can analyze that checkpoint variable and tell where
    to resume even if there are no line lables that PB could use
    to tell me other than even, say, only the first line in the
    program has a number (10) for example.

    That's particulary important when using in-line assembler, such
    as a Btrieve file interface where things can go bump. You either
    get to use line numbers for a trace purpose only, or code your
    own substitute for that, as you wish.

    As well, for very, very large projects, I've found it convenient
    to plan for the lowest level subroutine library modules to carry
    further and further numbers for the line labels toward the
    allowable cap level of 64555 or so. Your master line numbers in
    these subroutimes are, for example, all above 50000. That way
    you can create one key numeric line number lable in each SUB at the
    beginning of it, with the few critical other numeric lables at
    critical places in it. That will let you trap back to the places
    where things go wrong down deeper in nested code.

    From there we use, as Lance Edmonds taught me quite a while ago
    here, to be sure and use EXIT FAR to properly reflect back where
    we went bumppity bump! The use of this is NOT, as best as I
    can tell enhanced at all by the concept of RESUME NEXT. In fact,
    isn't such a thing totally counterproductive and at odds with
    the assignment of numerical line lables? They are limited you
    know! And you can have a number of lines of code inbetween
    consecutive numeric line labels as well.

    What would happen to RESUME NEXT in that case?

    Inquiring mind wants to know!

    I think one is wise to contemplate all this for another interesting
    reason.

    If you ever have to port PowerBASIC to another language, one of
    the things you will greatly miss is ... numeric line labels!
    They are both a pest and savior, as you may have already discovered.

    In a major port process for to take PB source to C of C++, I think
    you will find that you'll wind up creating pseudo-lables for each
    of the line lables you have in the PB source! That's what I wound
    up doing in the translator here.

    From there I created a trace trap integer counter for each location
    which takes the place of that line number. It then is the directive
    for the error trap routine you have to then use in the other
    programming forum to do what is so easy in PB.

    Since we started at RESUME NEXT for this pig trail,

    how would you suggest one contemplate finding
    the NEXT acorn for an error ****ing piglette,
    without a numeric ear tag for each step 'e takes?


    No, for those who have read Winnie The Pooh, I think RESUME NEXT
    is rather akin to poor Pooh with the honey bucket stuck on 'is
    head. A real bother indeed ..




    Plus ..


    It becomes a heck of a lot more introspective if your programs
    are up in the 25,000 line source range, I clue you. As does
    the burden of RESUME NEXT from an overhead standpoint.

    The code's not done, 'till there's too much to run!

    ------------------
    Mike Luther
    [email protected]

    Leave a comment:


  • Robert E. Carneal
    replied
    Michael, currently I only check for a few errors at the ON ERROR,
    the rest of them I simply RESUME NEXT. I will fix it to report
    each and every error. I had been using ERRADR wrong, thanks for
    pointing that out. A BIG thank you!

    Robert

    ------------------

    Leave a comment:


  • Michael Mattias
    replied
    The "pgm-ctr" error is NOT a "prgm-ctr" error. "Error 7" (insufficient memory) is the important value, and you can use the IDE option "Compile/Find Error" to convert a "pgm-ctr" into a distinct line of source code.

    Oops, forgot: if you are shelling your own PB/DOS programs, you can trap the errors simply by installing error traps with ON ERROR GOTO xxx. In your error-handler, you can PRINT the name of the program, the error code and ERRADR (ERRADR returns a "pgm-ctr" value which you can then trace back to a source code line as shown above).

    MCM




    [This message has been edited by Michael Mattias (edited August 14, 2001).]

    Leave a comment:


  • Mel Bishop
    replied
    I would recommend putting a pause before each shell. Your
    code modified: This is not exact of course, but it'll give
    you the idea.

    If Invntry < MinReqs then
    if Invntry < 0 then

    print;"Shelling to autordr.exe"
    while instat=0:wend
    temp$ = inkey$

    Shell "C:\stock\autordr.exe"
    else

    print;"Shelling to MinRegs.exe"
    while instat=0:wend
    temp$ = inkey$


    Shell "c:\Stock\MinReqs.exe" :'Min inventory required!
    end if
    else
    if Invntry > 40 then

    print;"Shelling to Ovrstock.exe"
    while instat=0:wend
    temp$ = inkey$


    Shell "C:\Stock\Ovrstck.exe":' TOO MUCH inventory!
    end if
    end if

    This should give you the program where the error occurs. Then
    you should be able to take care of it from there.

    Cheers
    Mel


    ------------------

    Leave a comment:


  • Robert E. Carneal
    started a topic PGM-CTR errors

    PGM-CTR errors

    In compile, my programs run fine. When I turn them into EXE
    files however, I encounter the pgm-ctr error. The following is
    the most common one.

    7 at pgm-ctr 308

    I can't even tell which program is triggering this error
    because my program constantly shells another EXE file. I have one
    "control" program that shells which ever program needed to run. Only
    variables in the "Control" program need to stay intact- the
    shelled to EXE variables do not need to be preserved.

    Example:
    If Invntry < MinReqs then
    if Invntry < 0 then
    Shell "C:\stock\autordr.exe"
    else
    Shell "c:\Stock\MinReqs.exe" :'Min inventory required!
    end if
    else
    if Invntry > 40 then
    Shell "C:\Stock\Ovrstck.exe":' TOO MUCH inventory!
    end if
    end if

    And so on. Is there a way to determine which line and program s
    triggering this type of error? I am hoping for a relatively easy
    way to do this so I can do it myself. I counted the Shells, and
    I have a total of 37 SHELLs. Is that the problem?

    Thanks!

    ------------------
Working...
X