I just realized that it would probably help if I posted a map to run with that code.

You need a folder named "Maps" in with the sketch, and two text files.  One should be called RoomIndex.txt, and it should have the line StartRoom.txt in it.  The other file should be called StartRoom.txt, and contain the following:

1. StartRoom
   10
   10
   5
   5
   5
   5
   4
   5
   5
   5
   5
   5
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   1
   7
   7
   7
   7
   7
   7
   7
   7
   3
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   5
   7
   7
   7
   7
   7
   7
   7
   7
   5
   5
   5
   5
   5
   2
   5
   5
   5
   5
   5
   

Thanks again to anyone who takes the time to look at this.

Do you mean your program crashes after being exported to an application, but not when running in the PDE?

You shouldn't catch exceptions like you do, on regular, innocent code... Particularly in draw(), where nothing is printed out, so it will fail silently. But in general, if you have errors like NullPointerException or ArrayIndexOutOfBoundsException, you must fix them by specific code (better bounds, conditions to avoid using a null variable) instead of using this general mechanism.

yeah get rid of catch exceptions

then insert println, e.g. at the end of setup or beginning of draw()

then you can see if he got this far and thus move println further on in your code.

When println isn't reached (look in the direct window after the crush), you know where the error is.

Hi, PhiLho.  Thanks for the reply.  I'm crashing when I try to run this in PDE.  I haven't tried to export it yet.

Thanks for your advice about exception handling.  A lot of those are temporary fixes, trying to figure out why it keeps crashing on me, although the one in the Draw function was an admittedly kludgey hack to get the code to stop running when there were no more open exits left on the map.  I've got an idea about how to fix it up now, but it's kind of moot while the thing keeps crashing.

Thanks, Chrisir.  I've been using println to track down crashes already - you can still see them in the code I posted.  It helped solve a couple of OutofBounds errors I was getting, but it's not helping with this crash, which doesn't seem consistent in where it appears.  It occasional dies while it's in the middle of printing out one of the println commands.

Later I can set up your sketch with its files to get a closer look, but now that you removed the try / catch, you should be able to report more precisely (error message, line where it happens) the error you get.

Thanks for taking the time to help me, PhiLo.  I've edited the code in my first post to remove the try/catch (also, reverted the "debug[0]=("Got exit 0: " + exits.get(0));" stuff back to println - that was gibberish code from an abortive debugging attempt.  Never fully implemented it, thought I'd taken it out before I posted the thread.)

Anyway, even without the try/catch, I'm not getting any error messages when it crashes.  Maybe this wasn't clear earlier, but my program isn't crashing within Processing, it's crashing the whole application.  About half the time I run it, the program chokes up.  The stop button and menu commands in the PDE are unresponsive, and I can't close either of the windows.  After a minute or so, the PDE crashes, but the display window won't go away unless I force it closed through the Task Manager.

This process doesn't produce any error messages, and trying to pin down where it's happening by printing to the output window doesn't help: the crash doesn't happen consistently in one place, and occasionally it happens right in the middle of outputting something to the output window.  I'll have a comment like, "Getting color value," and the program crashes in the middle of the word "color."

I still see some useless try / catch, but at least they printout something. But they prevent proper error pinpointing. Do you see the corresponding error messages you println? Aren't these messages hidden in a flow of other println()? It is better to have the sketch to crash with a relevant error message (and line), as you can then fix the reported error, instead of having a generic message telling "something wrong happened" without further detail!

Perhaps the PDE crashes because you print out too much information on the console. I have seen reports about that. You can reduce the amount of information to the pertinent parts, and, better, fix your errors...

Looks like taking out the printlns did the trick!  Thanks for your help, PhiLo!  I never would have figured out that outputting too much text like that would crash the whole program.