Announcement

Collapse
No announcement yet.

RESUME NEXT/GPF/Turning off/ and when

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

  • RESUME NEXT/GPF/Turning off/ and when

    'ErrorTrapTest.bas
    '1) Can ON ERROR RESUME NEXT be turned ON/OFF at run-time using this technique?
    '2) 'Why ever use RESUME NEXT?
    '3) 'What errors would ON ERROR RESUME NEXT prevent from a GPF?
    '
    'This code will run under PBCC or PBWIN.
    'Intentionally doesn't use ERRCLEAR to test ERR on return from CALL
    '
    Code:
      #COMPILE EXE
      #DIM ALL
      DECLARE SUB TEST(Counter AS LONG)
      DECLARE SUB DISPLAY(MyText AS STRING)  'allow displaying in PBCC or PBWIN
      '
      FUNCTION PBMAIN () AS LONG
        LOCAL Loops AS LONG
        FOR Loops = 1 TO 4
          Test(Loops)
          Display "ERR value after returing from call" + STR$(ERR)
        NEXT
        #IF %DEF(%PB_CC32)
          DISPLAY "Press any key to exit"
          WAITKEY$
        #ENDIF
      END FUNCTION
      '
      SUB TEST(Counter AS LONG)
        LOCAL s AS STRING
        ON ERROR GOTO 0                 'Assure error trapping is off
        IF Counter MOD 2 = 0 THEN
          ON ERROR RESUME NEXT          'Is this statement always active?
          s = "USING ON ERROR RESUME NEXT"
        ELSE
          s = "NO ON ERROR RESUME NEXT
        END IF
        OPEN "xx:fail.dat" FOR INPUT AS #1
        IF ERR THEN
          DISPLAY s + " Error" + STR$(ERR)
        END IF
    END SUB
    
    SUB Display(MyText AS STRING)
      #IF %DEF(%PB_CC32)
        PRINT MyText
      #ELSE
        MSGBOX MyText
      #ENDIF
    END SUB
    ------------------
    The world is full of apathy, but who cares?

  • #2
    The way I read the help, ON ERROR GOTO 0 is identical to ON ERROR RESUME NEXT:

    To disable error trapping, use ON ERROR GOTO 0 or ON ERROR RESUME NEXT.
    >'Intentionally doesn't use ERRCLEAR to test ERR on return from CALL

    ERR - once set - will not reset itself. You must use ERRCLEAR or ERR=0 to do so.

    >What errors would ON ERROR RESUME NEXT prevent from a GPF?

    ON ERROR will never in and of itself prevent a GPF. All it will do is branch to the designated routine when ERR is set.

    #DEBUG ERROR ON will prevent GPFs from attempts to use a null pointer or an array out of bounds. (Also sets ERR=9 for use with error-trapping)



    [This message has been edited by Michael Mattias (edited August 12, 2006).]
    Michael Mattias
    Tal Systems (retired)
    Port Washington WI USA
    [email protected]
    http://www.talsystems.com

    Comment


    • #3
      You're right. Turns off error trapping.
      Why not ON ERROR RESUME OFF?
      RESUME NEXT seems to imply turning it on (to me, anyway.)
      '
      I think other programming lanuguges use it at the
      top of SUB's and FUNCTIONS so they handle errors
      like PB automatically does now by going to the
      line after the error. RESUME NEXT isn't used
      the same way, if I have this right.
      '
      In other words, ON ERROR RESUME NEXT and ON ERROR RESUME 0
      would be used when ON ERROR LABEL was used. Then it would
      return to the line after the one that created the error.

      Thank you

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


      [This message has been edited by Mike Doty (edited August 12, 2006).]
      The world is full of apathy, but who cares?

      Comment


      • #4
        'Now it makes sense.
        Code:
          #COMPILE EXE
          #DIM ALL
          DECLARE SUB DISPLAY(MyText AS STRING)  'allow displaying in PBCC or PBWIN
          '
          FUNCTION PBMAIN () AS LONG
            LOCAL s AS STRING
            ON ERROR GOTO ErrorTrap
            OPEN "xx:fail.dat" FOR INPUT AS #1
            Display "Continue here and clear error number" + STR$(ERRCLEAR)
            Display "Error is now" + STR$(ERR)
            #IF %DEF(%PB_CC32) 'ooops, correct later
              display "Press any key to end"
              WAITKEY$
            #ENDIF
        EXIT FUNCTION
        ErrorTrap:
            Display "In ErrorTrap and error is" + STR$(ERR)
            'never clear error before RESUME NEXT (won't return to line after error)
            'ON ERROR GOTO 0 'this will not return!!!! Thanks, Michael
            RESUME NEXT     'or this
        END FUNCTION
        
        SUB Display(MyText AS STRING)
          #IF %DEF(%PB_CC32)
            PRINT MyText
          #ELSE
            MSGBOX MyText
          #ENDIF
        END SUB
        ------------------




        [This message has been edited by Mike Doty (edited August 12, 2006).]
        The world is full of apathy, but who cares?

        Comment


        • #5
          IIRC, "traditional" BASIC only offered "ON ERROR GOTO n", and if n were zero, it meant "disable branch on error" and the "ON ERROR RESUME NEXT" syntax was an extension added by PowerBASIC Inc.

          The RESUME statement itself is never used except whilst in an error trapping routine.

          I can see how putting the RESUME keyword into the ON ERROR GOTO statement might be a bit confusing.

          Michael Mattias
          Tal Systems (retired)
          Port Washington WI USA
          [email protected]
          http://www.talsystems.com

          Comment


          • #6
            Mike that code is going to fail at some point
            Code:
            ErrorTrap: 
               Display "In ErrorTrap and error is" + STR$(ERR)    'never clear error before RESUME NEXT (won't return to line after error)
               ON ERROR GOTO 0 'this 
               'RESUME NEXT     'or this
            END FUNCTION
            All Error Traps MUST exit with a RESUME. This I know for sure.

            And while it may work in this limited demo, something in the back of my head is saying, "Never use ON ERROR GOTO within an error-trapping routine"

            I don't use "ON ERROR GOTO xxx " very often; I just check ERR inline. Maybe someone else uses ON ERROR GOTO more often and can offer some suggestions.

            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              'Michael, you are right! ON ERROR RESUME NEXT needed.
              'I think the docs may be in error in one place.
              'ON ERROR RESUME NEXT does not disable error trapping as
              'stated in ON ERROR statement (page 452 in manual.)
              Code:
                #COMPILE EXE
                #DIM ALL
                DECLARE SUB DISPLAY(MyText AS STRING)  'allow displaying in PBCC or PBWIN
                '
                FUNCTION PBMAIN () AS LONG
                  LOCAL s AS STRING
                  ON ERROR GOTO ErrorTrap
                  OPEN "xx:fail.dat" FOR INPUT AS #1
                  Display "Continue here and clear error number" + STR$(ERRCLEAR)
                  Display "Error is now" + STR$(ERR)
                  Display "Now creating the same error"
                  OPEN "xx:fail.dat" FOR INPUT AS #1
                  Display "Continue here and clear error number" + STR$(ERRCLEAR)
                  Display "Error is now" + STR$(ERR)
              
              
                  #IF %DEF(%PB_CC32)
                    display "Press any key to end"
                    WAITKEY$
                  #ENDIF
              EXIT FUNCTION
              ErrorTrap:
                  Display "----    In ErrorTrap and error is" + STR$(ERR) + " ----"
                  'ON ERROR GOTO 0 'disable error trapping
                  RESUME NEXT      'does not disable error trapping
              END FUNCTION
              
              SUB Display(MyText AS STRING)
                #IF %DEF(%PB_CC32)
                  PRINT MyText
                #ELSE
                  MSGBOX MyText
                #ENDIF
              END SUB
              '
              '----------------------------------------------------------
              'Actually Microsoft Basic used ON ERROR RESUME NEXT.
              'Code had to be compiled using the /X switch.
              '
              'DEFINT A-Z
              'ON ERROR RESUME NEXT
              'PRINT 9 / x


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




              [This message has been edited by Mike Doty (edited August 12, 2006).]
              The world is full of apathy, but who cares?

              Comment


              • #8
                If you want to reset ERR before returning from the error trap it may be better to use
                ERR=0 instead of ERRCLEAR.

                When ERRCLEAR is used in the error trap:
                RESUME NEXT is ignored and program will fail to continue execution on the line following the error.
                RESUME LABEL works as expected however!

                When ERR=0 is used in the error trap both RESUME NEXT and RESUME LABEL work as expected.
                Code:
                ErrorTrap:
                    Display "----    In ErrorTrap and error is" + STR$(ERR) + " ----"
                    'Using ERRCLEAR here prevents RESUME NEXT working
                    ERR=0           ' Not equivalent to ERRCLEAR !!
                    RESUME NEXT     ' continue execution at line after error
                END FUNCTION
                Rgds Dave

                ------------------
                Rgds, Dave

                Comment


                • #9
                  Dave,
                  Thanks much.
                  It works as expected when this is done!
                  .
                  Note: Documentation, page 347 on ERR and ERRCLEAR
                  ERRCLEAR, when used as a statement, is equivalent to ERR=0
                  Picky, picky ...
                  ------------------


                  [This message has been edited by Mike Doty (edited August 13, 2006).]
                  The world is full of apathy, but who cares?

                  Comment


                  • #10
                    >Picky, picky

                    No: buggy buggy.

                    Either the doc is wrong or the compiler is not behaving correctly, since ERR=0 and ERRCLEAR are not equivalent. That's what a bug is.


                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      Submitted to [email protected]
                      Received an email that this has been reported to R&D
                      and told to use ERR=0 until this is resolved.

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




                      [This message has been edited by Mike Doty (edited August 14, 2006).]
                      The world is full of apathy, but who cares?

                      Comment

                      Working...
                      X