Applesoft/Prodos/ONERR GOTO/File existence question

[Eric Smith <eric-no-spam-for-me@brouhaha.com>]

Hans Franke and I submitted an entry to the Retrocode competition at
VCF 6.0 today, and came in second.  I had a bit of a problem in one
area, and thought maybe one of you experts out there might offer a
suggestion.

The code looked vaguely like this:

10 DIM M%(38,38)
20 GOSUB 10000: REM Load or generate maze

...

10000 GOSUB 20000: REM Try to load maze from data file
10010 IF M%(0,0)=15 THEN RETURN: REM Loaded maze
10020 REM Generate a new maze
...
10500 REM Write maze to file
10510 PRINT CHR$(4);"OPEN MAZE.DAT"
10520 PRINT CHR$(4);"WRITE MAZE.DAT"
... nested loops with PRINT statements
10580 PRINT CHR$(4);"CLOSE MAZE.DAT"
10590 RETURN

...

20000 REM Try to read maze from file
20010 ONERR GOTO 20040: REM In case the file doesn't exist
20020 PRINT CHR$(4);"OPEN MAZE.DAT"
20030 PRINT CHR$(4);"READ MAZE.DAT"
... nested loops with INPUT statements
20040 PRINT CHR$(4);"CLOSE MAZE.DAT"
20050 POKE 216,0: REM Cancel ONERR
20060 RETURN

I'm not claiming that this is particularly good style.  We only had 3 hours
to write the whole contest entry, and most of the time was spent on the game
algorithms and debugging.

Anyhow, the problem was that any time the program was run without a
preexisting MAZE.DAT file, it would get the error and trap to line 20050,
but when it got to the RETURN statement in 20060, it would then get a
RETURN WITHOUT GOSUB error.

So I have two questions:

1)  Does an error trapped using ONERR really lose the subroutine stack?
    Or do I need to do something else to make the RETURN work?  Note that
    I definitely do NOT want to RESUME the statement that caused the
    error.

2)  Is there a better way from a BASIC program to determine the existence
    of a file?

I presume the answer to my second question would probably be different
for DOS as opposed to Prodos.

For those that are curious, the game was originally intended to be a
first-person maze game with monsters to fight.  However, we spent nearly
45 minutes of our alloted three hours getting a second Apple working.
(About three different things bit us.  We ended up borrowing another IIgs
from an exhibitor.)

Since we ran out of time, we ended up with an overhead 2D view instead,
because I already had written the 2D display in lores graphics to debug
the maze generator.  The result was similar to the old "Dragon Maze" game,
but with the entire maze visible and nine monsters wandering around.
I estimate that the first person view could have been completed in another
half hour or so.  Maybe I'll try that next weekend.

Generating a maze took over a minute, so I added the code to save and
reload the maze to speed up debugging of the rest of the game.

At the moment I don't have a convenient way to transfer the program to
another computer to put it on the web, but I'll do that eventually.

This was the first non-trivial Applesoft program I've written in 17 years,
and even back then I mostly programmed the Apple in other languages,
mostly assembler (using Microsoft ALDS), XPL0, Apple Pascal, or
Kyan Pascal.  These days the vast majority of the code I write is in C,
with occasional assembly for hardware-related code.

Thanks,
Eric