TSEMM@ALASKA.BITNET ("Edward M. Moore") (03/20/91)
I'm trying to design a program using gosubs. One of the sections is where I have a file-handeling (loading a shape table) from disk. I would like to use OnErr Goto in order to handle the error, but when that happens I loose my stack of gosubs. How can this be prevented? TSEMM@ALASKA TSEMM@ALASKA.bitnet
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (03/20/91)
TSEMM@ALASKA.BITNET ("Edward M. Moore") writes: >I'm trying to design a program using gosubs. One of the sections is >where I have a file-handeling (loading a shape table) from disk. I would >like to use OnErr Goto in order to handle the error, but when that happens >I loose my stack of gosubs. How can this be prevented? I don't have the book, but the original AppleSoft Reference Manual had a poke/call method to do that. If anybody has one of those ancient texts, could you dust it off and look it up? I'm pretty sure it's in one of the appendices, but it shoud be on one of the pages listed for ONERR GOTO in the index. Todd Whitesel toddpw @ tybalt.caltech.edu
stephens@latcs1.oz.au (Philip J Stephens) (03/20/91)
"Edward M. Moore" writes: > I'm trying to design a program using gosubs. One of the sections is > where I have a file-handeling (loading a shape table) from disk. I would > like to use OnErr Goto in order to handle the error, but when that happens > I loose my stack of gosubs. How can this be prevented? Most BASIC's should have a statement called "RESUME" that allow's you to re-enter the program at the point that the error occurred. If it doesn't, then you're either going to have to use a global variable to act as a indicator of where you were before the error occurred, or delve deeper into the mechanics of the BASIC interpreter/compiler. Sorry, but I can't see how I can be of more help! </\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\> < Philip J. Stephens >< "Many views yield the truth." > < Hons. student, Computer Science >< "Therefore, be not alone." > < La Trobe University, Melbourne >< - Prime Song of the viggies, from > < AUSTRALIA >< THE ENGIMA SCORE by Sheri S Tepper > <\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>
bazyar@ernie (Jawaid Bazyar) (03/21/91)
>"Edward M. Moore" writes: > I'm trying to design a program using gosubs. One of the sections is > where I have a file-handeling (loading a shape table) from disk. I would > like to use OnErr Goto in order to handle the error, but when that happens > I loose my stack of gosubs. How can this be prevented? I seem to recall there being a bug with Applesoft's error handling routines that could cause it to forget the gosub stack in certain cases. A few pokes correct the problem, but offhand I wouldn't know what they were (it's been years since I hacked Applesoft). A good place to find out would be "What's Where in Your Apple II", the all-time Applesoft Hacker's Bible. I might have the proper code in my old Basic BBS program- I'll see if I can find it (the program's a nasty mess though, so no guarantees). -- Jawaid Bazyar |"I'm sure K&R have never heard of Mike." Senior/Computer Engineering | bazyar@cs.uiuc.edu |"That's okay. I'm sure Mike's never heard of K&R". Apple II Forever! | (discussion about Orca/C)
estell@m.cs.uiuc.edu (John Estell) (03/21/91)
bazyar@ernie (Jawaid Bazyar) writes: >>"Edward M. Moore" writes: >> I'm trying to design a program using gosubs. One of the sections is >> where I have a file-handeling (loading a shape table) from disk. I would >> like to use OnErr Goto in order to handle the error, but when that happens >> I loose my stack of gosubs. How can this be prevented? > I seem to recall there being a bug with Applesoft's error handling >routines that could cause it to forget the gosub stack in certain cases. A >few pokes correct the problem, but offhand I wouldn't know what they were Adapted from the Applesoft Basic Programming Reference Manual, p. 136: 10 FOR I=768 TO 777 : READ X : POKE I, X : NEXT 20 DATA 104, 168, 104, 166, 223, 154, 72, 152, 72, 96 "Establishes a machine-language routine at location 768, which can be used in an error-handling routine. Clears up some ONERR GOTO problems and ?OUT OF MEMORY ERROR messages. Use the command CALL 768 in the error- handling routine." Hope this helps. ------------------ NAME: John K. Estell USPS: CS Dept - Univ of Illinois, 1304 W. Springfield, Urbana, IL 61801 ARPA: estell@cs.uiuc.edu UUCP: ...!{uunet,harvard}!uiucdcs!estell VOICE: "Hi John!" QUOTE: CHR$(34)
koppenh@dia.informatik.uni-stuttgart.de (Andreas Koppenhoefer) (03/22/91)
In article <9103191800.AA11676@apple.com> TSEMM@ALASKA.BITNET ("Edward M. Moore") writes:
Path: ifistg!ira.uka.de!sol.ctr.columbia.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac,att!ucbvax!ALASKA.BITNET!TSEMM
From: TSEMM@ALASKA.BITNET ("Edward M. Moore")
Newsgroups: comp.sys.apple2
Date: 19 Mar 91 17:57:12 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 7
I'm trying to design a program using gosubs. One of the sections is
where I have a file-handeling (loading a shape table) from disk. I would
like to use OnErr Goto in order to handle the error, but when that happens
I loose my stack of gosubs. How can this be prevented?
TSEMM@ALASKA
TSEMM@ALASKA.bitnet
There is no need to use any machine language, CALL or POKE. Just look
at the following code, which tries to bload some stuff into memory.
10 PRINT "CALLING SUBROUTINE"
20 GOSUB 100
30 PRINT "FINISHED":END
...
100 ONERR GOTO 150
110 ER = 1 : IF ER THEN PRINT CHR$(4)"BLOAD STUFF"
120 POKE 216,0 : IF NOT ER THEN PRINT "CANNOT LOAD FILE 'STUFF'";CHR$(7)
130 RETURN
150 POKE 216,0: IF ER THEN ER = 0 : RESUME : REM error in line 110!
160 PRINT "THERE IS AN UNEXPECTED ERROR":REM This should not happen!
170 STOP
Think about it and try it. It will work under every applesoft basic I know.
Remarks: If DOS or PRODOS returns an error for the BLOAD command, then
basic will continue with the error handler in 150. The following
RESUME tries to restart the basic commands that caused the error. It's
the IF statement in 110 and not the PRINT statement in the same line.
The interpreter thinks about an 'IF <expr> THEN <command>' as a single
statement!!! BUT now the variable ER is set to zero, the if-clause evals
to false and the interpreter jumps to the next line in 120. All your
stack contents (RETURN-addresses, etc.) remains intact!
Greetings
Andreas
--
Andreas Koppenhoefer, Student der Universitaet Stuttgart, BR Deutschland
X400: koppenh@dia.informatik.uni-stuttgart.dbp.de
SMTP: koppenh@dia.informatik.uni-stuttgart.de
privat: Belaustr. 5/3, W-7000 Stuttgart 1, Germany, +49 711 694111 (18-22h MEZ)mranger@pro-odyssey.cts.com (Richard Kissel) (03/22/91)
In-Reply-To: message from toddpw@nntp-server.caltech.edu Try this out 10 home ONERR GO 30 POKE 1010,102:POKE 1011,213:POKE1012,112 THEN AT THE END OF THE PROGRAM TURN OFF WITH POKE 1010,1:POKE 1011,157:POKE 1012,56 THIS SHOULD WORK.... ---- ProLine: mranger@pro-odyssey Internet: mranger@pro-odyssey.cts.com UUCP: crash!pro-odyssey!mranger ARPA: crash!pro-odyssey!mranger@nosc.mil
aford@pro-mansion.cts.com (Adam Ford) (03/23/91)
In-Reply-To: message from toddpw@nntp-server.caltech.edu ONERR GOTO removed ALL GOSUBS from memory. +--------------------------------------------+-------------------------------+ |ProLine: aford@pro-mansion | E-Mail me for a good | |Internet: aford@pro-mansion | | |UUCP: crash!pro-mansion!aford | Signature | |ARPA: crash!pro-mansion!aford@nosc.mil | | |BitNet: aford%pro-mansion.cts.com@nosc.mil| | +--------------------------------------------+-------------------------------+
koppenh@dia.informatik.uni-stuttgart.de (Andreas Koppenhoefer) (03/27/91)
In article <8155@crash.cts.com> aford@pro-mansion.cts.com (Adam Ford) writes:
Path: ifistg!ira.uka.de!sol.ctr.columbia.edu!ucselx!crash!pro-mansion.cts.com!aford
From: aford@pro-mansion.cts.com (Adam Ford)
Newsgroups: comp.sys.apple2
Date: 23 Mar 91 11:16:04 GMT
Sender: root@crash.cts.com
Lines: 13
In-Reply-To: message from toddpw@nntp-server.caltech.edu
ONERR GOTO removed ALL GOSUBS from memory.
That's incorrect! ONERR GOTO leaves everything intact on stack
memory. After a RESUME operation all those RETURN statements will do
their jobs again!
--
Andreas Koppenhoefer, Student der Universitaet Stuttgart, BR Deutschland
X400: koppenh@dia.informatik.uni-stuttgart.dbp.de
SMTP: koppenh@dia.informatik.uni-stuttgart.de
privat: Belaustr. 5/3, W-7000 Stuttgart 1, Germany, +49 711 694111 (18-22h MEZ)