Cleaning up after ON ERROR GOTO

[Rob Gaddi]

So I'm trying to make sure that I'm writing non-leaky code, and realized that I don't know how PBDOS 3.5 handles the following:

SUB MyBigSub
  ON LOCAL ERROR GOTO Handler

  CALL LittleSub1
  CALL LittleSub2

Handler:
  SELECT CASE ERRCLEAR
    CASE 0
    CASE ELSE
      RESUME EndOfSub
  END SELECT

EndOfSub:
  PRINT "Done"
END SUB

So the LittleSubs may throw errors, and if they do, I just want to be done with the whole process and dump back to the main code. Does anyone know a) Does the stack get properly unwound in all of that and b) If I have DYNAMIC variables in the LittleSubs, will they get deallocated by that?

Or does this all not work and I should be giving each LittleSub it's own error handler and EXIT FAR?

[Mike Doty]

'In PB/CC and PBWin errors are all local to functions and subs
'ERRCLEAR should be ERR since it will always change ERR to 0
'Falling into Handler should be avoided
'This is PB/CC code, but should apply for the most part.

#COMPILE EXE
#DIM ALL
FUNCTION PBMAIN () AS LONG
  MyBigSub
  WAITKEY$
END FUNCTION
SUB MyBigSub
  ON ERROR GOTO Handler
  CALL LittleSub1
  CALL LittleSub2
   'ERROR 0               'illegal, cause runtime error 5
  ? "Back from setting ERROR"
  ? "The value of err" + STR$(ERR)
'EXIT SUB    'add this so you don't fall through error handler
  ? "Incorrect, fall into error handler because not EXIT SUB above
Handler:
  ? "Handler starts with ERR=" + STR$(ERR)
  'SELECT CASE ERRCLEAR                  'wrong, ERRCLEAR alway sets ERR to 0
  SELECT CASE ERR
    CASE 0: ? "In Handler and err is" + STR$(ERR)
    CASE ELSE
      ? "Some error occurred" + STR$(ERR)
      RESUME EndOfSub                     'this handles all errors
  END SELECT
  ? "Falling out of error handler"
EndOfSub:
  PRINT "Done"
END SUB
 
SUB LittleSub1
  ? "LittleSub1"
END SUB
SUB LittleSub2
  ? "LittleSub2"
END SUB

[Michael Mattias]

>) Does the stack get properly unwound in all of that and b) If I have DYNAMIC >variables in the LittleSubs, will they get deallocated by that?

Yes and.. I think yes, if DYNAMIC refers to array variables.. (Come to think of it, that's the only thing it CAN mean).

>and EXIT FAR?

EXIT FAR is used primarily to escape recursion. although I suppose it could be used to escape a deeply nested set of procedure calls (A calls B calls C calls D calls E... Oops, I want to go back to A now).

It is never necessary to use EXIT FAR at all. (Personally I think EXIT FAR is a lazy way to program, but I'm guessing I'm in a minority on that).

[Mike Luther]

EXIT FAR has been supremely helpful for clearing really difficult memory corruption problems in DOS-VDM for OS/2 PB 3.5 development work. Especially where every line of source code does not contain a numeric line number.

Please, I do NOT want to open up any issues on the memory corruption deal.

All I am saying is that without using the EXIT FAR technique, when you are using huge PB created executables with 20,000 lines of source and larger, 2000+ global variables, especially if you are using Segment sizes which are close to the 64K boundary and can't even use the development system on 629K DOS memory availability for run-time debugging; the ONLY way I have ever been able to stabilize the error handling operations such that I can even begin to de-bug errors that are nested in library modules and in other than the distinct main segment, is to use the EXIT FAR offering from PB.

[Michael Mattias]

Mike, you need to bite the bullet and rewrite that app.

There's only so many upgrades and enhancements you can add to any program before the cost of modifying it again exceeds the cost of starting over.