RESUME NEXT/GPF/Turning off/ and when

[Mike Doty]

'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
'

  #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

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

[Michael Mattias]

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).]

[Mike Doty]

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).]

[Mike Doty]

'Now it makes sense.

  #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).]

[Michael Mattias]

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]

Mike that code is going to fail at some point

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.

[Mike Doty]

'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.)

  #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).]

[Dave Biggs]

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.

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

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

[Mike Doty]

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).]

[Michael Mattias]

>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.

[Mike Doty]

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).]